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ABSTRACT 


This thesis examines the requirements and design of a financial management 
system for the academic departments at the Naval Postgraduate School. Existing 
systems are difficult to maintain and/or provide out-of-date information. A system 
is needed that is easy to use, easy to maintain, and provides current account status 
information so that the academic departments can make intelligent financial decisions. 

We examined existing methods and tools for designing and building 
client/server applications. After comparing the traditional waterfall approach to the 
rapid prototyping approach, we elected to use rapid prototyping in order to develop 
the system quickly and to help the users determine their own requirements. We 
decided to use the Powersoft Portfolio tool set from Powersoft Corporation because 
it is scalable, transportable, affordable, and compliant with the Open Database 
Connectivity standard. 

The result of this thesis is a prototype financial management system that users 
have found easy to use and maintain. The system provides summary and detail 
information on departmental financial accounts, to include balances and expenditures 
in the funding categories of faculty and support labor, equipment, travel, and 


contracts. 
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I. INTRODUCTION 


A. BACKGROUND 

The academic departments of the Naval Postgraduate School need a method to 
provide current status information for their numerous financial accounts. Reports from the 
Comptroller are quarterly and are frequently out-of-date when received. Without up-to-date 
information, the departments cannot make intelligent financial decisions. Although solutions 
to this problem have been developed, they do not provide a complete or efficient solution to 
the problem. This thesis determines the requirements and design for a financial management 
system for the academic departments. 
B. REVIEW OF EXISTING SYSTEMS 

1. Operations Research Department System 

The Operations Research Department has a system that was developed using Borland 
Paradox for DOS. It was loosely based on a system that had been developed for the 
Administrative Science Department (now known as the Systems Management Department) 
using dBase IV [Ref. 1, 2, 3, 4, 5]. Neither the Administrative Science Department’s 
database nor the Operations Research Department’s database was designed using proper 
database design techniques, i.e., no data modeling was done such as through the use of 
Entity-Relationship (ER) diagrams or Enhanced Entity-Relationship (EER) diagrams [Ref. 
6]. The Administrative Science Department’s system was not easy to maintain and not easily 


transportable to other departments. 


The Operations Research Department’s system, named the “Paradox-based Financial 
Management Information System (PFMIS), allowed the inputting of account, labor, 
equipment, and travel information but only calculated the balance of accounts for the labor 
category. The version of Paradox used does not support storage of embedded code, such as 
Structured Query Language (SQL) code, in the database. Instead, scripts written in the 
“Paradox Application Language” have to be manually executed to perform calculations such 
as those needed to determine the balance of an account. More sophisticated databases allow 
embedded code, known as triggers and stored procedures, which can cause calculations or 
other actions to happen automatically upon insertion, modification, or deletion of data in the 
database. 

2: Computer Science Department System 

The Computer Science Department system is based on the Microsoft Excel 
spreadsheet. As such, it does not have many of the important features of a database system. 
For example, it cannot check that the user is inputting valid data, it cannot provide various 
levels of security to the data such as allowing some users read-only access and other users 
read-write access, it cannot provide transaction tracking and the ability to cancel transactions, 
it cannot provide the necessary protection to data that would allow simultaneous inputting 
of data by multiple users, and it cannot easily provide on-line access to individual professors 
of the status of their accounts. To provide account status information to the professors, the 
individual who inputs the data into Excel runs a program that converts a spreadsheet 
containing summary status information into a HyperText Markup Language (HTML) 


document. The HTML document is then posted on a World Wide Web page where the 


NO 


professor can view it. A database system, on the other hand, would allow the professors to 
access the database at any time to view the status of an account or the database system could 
be set to automatically update a Web page whenever new data was entered. In short, the 
Computer Science Department is attempting to solve a database problem using a spreadsheet. 

This thesis uses an approach that will use modern design techniques to provide a 


robust financial accounting system that is easy to use and maintain. 


Lad 





ll. SYSTEM REQUIREMENTS AND DESIGN 


A. PROJECT SCHEDULE 

The first step in the project was to develop a project schedule. A copy of the schedule 
is given in Appendix A. The project was divided into three main phases: a design phase, a 
development phase, and a test/debug phase. Each of these phases consisted of a variety of 
tasks. It was determined that many of the tasks could be done in parallel. To begin the 
project, system requirements were determined and software tools were selected. The 
Operations Research Department was selected as the test department for the project. 
B. SYSTEM REQUIREMENTS 

System requirements were developed by studying the existing system in the 
Operations Research Department and by conducting interviews with key personnel in that 
department to determine what tasks they needed to perform [Ref. 7]. The system 
requirements were determined to be as follows. 

1. General Requirements 


@ Track the department’s financial accounts. All type of accounts need to be 
tracked, e.g., Reimbursable Research (RR), Direct Research (DR), Direct Teach 


(DT), etc. 


@ Track the total dollar amount of each account, as well as the subcategories that the 
funds are broken out to, i.e., faculty labor, support labor, travel, OPTAR, and 
contracts. 


© Data must be exportable, i.e, the user’ must be able to bring data from the system 
into a spreadsheet or other program for manipulation. 


@ Security down to the “field” level so that only authorized users can read and/or 
write fields, records, and tables. 


@ The “front end” of the system must be compatible with Windows 3.1x, Windows 
95, Mac OS, and common variations of the Unix operating system, such as Sun 
Solaris. 


2. Read Access (Queries) 


@ Determine the balance in an account broken out into the following subcategones: 
faculty labor, support labor, travel, OPTAR, and contracts. 


@ List all charges against an account and see which charges are obligations (funds 
committed but not spent) versus actual expenditures. 


3. Write Access (Updates) 


@ Write access (updates) must be limited to authorized users in the department to 
help ensure the accuracy of the database. 


@ Authorized users should be able to enter information about initial funds in an 
account and charges against accounts. Charges against accounts will be in the 
subcategories of faculty labor, support labor, travel, OPTAR, and contracts. If 
possible, this information should come from other systems, e.g., SACONS 
(Standard Automated Contracting System), to avoid duplicate entry of data. 


'For these requirements, the term “user” refers to any authorized user of the 
system, e.g., a staff member who inputs data, the department chairman, and faculty 
members who are the Principle Investigators for accounts. 
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Report Generation 


The user should be able to produce the faculty and staff labor certification reports 
for each pay period. These reports show the number of hours of labor each week 
charged to specific accounts for each employee. The system should include some 
calendar functions so that it will automatically account for holidays, etc. 


The system must have the ability to easily produce custom reports such as lists of 
accounts and employees, lists of expenditures on accounts, and so on. 


C. SELECTION OF SOFTWARE TOOLS 


At the same time that the requirements were being developed, software tools to aid in 


the design of the database and the development of the application were examined. The 


desired features of the tools were: 


Affordable 
Scalable 


An established product. By purchasing an established product, it would more 
likely have support available through a variety of sources to include user groups 
and third-party books. 


Ease of use. The tools needed to be relatively easy to learn to use. 


Require a minimum of coding. By minimizing coding the resulting system would 
be easier to maintain. 


Transportable. In other words, able to implement on an IBM-compatible PC, 
Macintosh, or Unix-based system. 


Compliant with the ODBC (Open Database Connectivity) standard developed by 
Microsoft. Compliance with this standard would allow the application to interface 
with any ODBC compliant database such as Oracle or Sybase SQL Server. This 
would prevent the design from being locked in on one product/vendor for 
implementation. 


The products that were considered included: Powersoft Portfolio, Symantec Enterprise 
Developer, Oracle Database Server and Oracle Power Objects, and Borland Delphi. The 
decision was made to select Powersoft Portfolio because it provided a database design tool 
(S-Designor AppModeler, formerly, StarDesignor), an application development tool 
(PowerBuilder Desktop), and a database server (Sybase SOL Anywhere, formerly, Watcom 
SOL Server), it met all of the desired features, and it was the most affordable. 

D. DATABASE DESIGN 

1. The Enhanced Entity Relationship Diagram 

After the system requirements had been determined, the database was designed using 
an Enhanced Entity-Relationship (EER) diagram [Ref. 6]. The EER diagram, minus the 
attributes, is shown in Figure 1. The attributes for each entity and relationship are shown in 
Tables 1 and 2 respectively. The EER diagram was developed based on the system 
requirements, interviews with users of the system, and desired reports (output) from the 
system. The completed EER diagram was used to determine what tables to create, what 
attributes to have in each table, and what relationship existed between tables [Ref. 6]. 

2. The Physical Data Model 

The database design tool included with Powersoft Portfolio, S-Designor AppModeler, 
could not be used to create EER diagrams. Instead, the user graphically creates database 
tables, enters the attributes for each table, and then creates the relationships between tables. 
This is what S-Designor AppModeler refers to as the “physical data model.” Once the 
physical data model is complete, the user can generate any number of ODBC compliant 


databases, such as Oracle, Sybase SQL Anywhere, Microsoft Access, Borland Paradox, etc. 


For this project, once the physical data model had been created from the EER diagram, the 
physical data model was used as the design for the database. In other words, as the design 
was changed over time, the physical data model was updated, not the EER diagram. This was 
done for practical reasons. Changes could easily be made to the physical data model using 
S-Designor AppModeler. No tool was available to easily change the EER diagram. After 
making changes to the physical data model, the database could be modified automatically 
using S-Designor AppModeler to generate and execute the SQL code. Making changes to 
the EER diagram could not, of course, be used to change the database automatically since S- 
Designor AppModeler could not work with the EER diagram. The physical data model is 
shown in Figure 2. 

The user of S-Designor AppModeler does have to provide some of the intelligence for 
modifying the database, i.e., S-Designor AppModeler cannot successfully implement all 
modifications to the database. If multiple changes need to be made to the database, the user 
might have to enter one change at a time to the physical data model and have S-Designor 
AppModeler modify the database after each change to the physical data model in order to 
have the changes implemented properly. This is not always the case. It depends on what 
changes are being made to the database. For example, if non-key attributes (fields) are being 
added to some of the tables, this could be done all at once. If, however, a key attribute was 
being added or removed from a table along with other changes to the same table, the changes 


would have to be done individually. 
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Figure 1. Enhanced Entity Relationship Diagram (Minus Attributes) 
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Table 1. Attributes of Entities. 
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Ui. FINANCIAL MANAGEMENT SYSTEM 


A. CLIENT/SERVER PROCESSING DECISION 

We (my thesis advisor and I) decided to call the system the “Financial Management 
System” (FMS). Once the design of the Financial Management System database was 
complete, the development phase began. The solution being implementing utilized the 
“client/server” model of computing [Ref. 8] where some of the computing (processing) 1s 
done by the database residing on a “server” (a PC running the database server, in our case) 
and some of the computing is done by the application which runs on the “client” machine 
(again a PC in our case). A key part of the development phase was determining what would 
be done by the database (“back-end”), and what would be done by the application (‘“‘front- 
end”). 

1. Database (Back-end) Processing 

The database (back-end) handles the referential integrity constraints using triggers and 
it handles the calculation of the balance of the accounts using stored procedures. The reason 
for handling the referential integrity constraints using triggers is that S-Designor AppModeler 
automatically generated most of the triggers to enforce referential integrity thus having the 
tool do most of the work and making the database easier to maintain. The reason for 
calculating the balance of the accounts using stored procedures is so that the procedure would 
have to be written only once. It can be called by any trigger that would affect the balance of 


an account. Otherwise the code to calculate the balance of an account would have had to be 


placed in every trigger that affects the balance of an account. A listing of the triggers is given 
in Appendix B, and a listing of the stored procedures is given in Appendix C. 

Handling “referential integrity constraints” refers to ensuring the consistency of the 
data. In a relational database, a parent-child relationship can exist between tables. With a 
parent-child relationship, one or more records in the “child” table can refer to a record in the 
“parent” table. For example, in the FMS database there is a “parent” table called 
“DEPARTMENT” that contains information about academic departments such as the 
department code, department name, etc. A “child” table of DEPARTMENT is the table 
called “EMPLOYEE” which contains information about employees to include the department 
code of the department they belong to. The referential integrity constraint triggers in a 
database ensure that, for example, a record in the DEPARTMENT table cannot be deleted 
if EMPLOYEE records still exist with that department code (i.e., there are one or more 
records in the “child” EMPLOYEE table which reference the record to be deleted in the 
“parent” DEPARTMENT table). Figure 3 shows the attributes of the EMPLOYEE and 
DEPARTMENT tables and the arrow in the Figure from the attribute DEPT_CODE in the 
EMPLOYEE table to the attribute by the same name in the DEPARTMENT table illustrates 
the reference. 

These integrity constraint “triggers” are Structured Query Language (SQL) code [Ref. 
6] that are automatically executed upon occurrence of an event. The events that cause 
triggers to executer (“fire”) are inserting, updating, and deleting of records. Triggers can be 
set to occur either before or after each of these events. S-Designor AppModeler 


automatically creates integrity constraints triggers for tables that have parent-child 
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relationships. The tasks performed by the tnggers automatically created by S-Designor 
AppModeler include: 

@ The insert triggers ensure that a “parent” record exists (in the parent table) for 
every record inserted in a “child” table. If the parent record does not exist, the 
trigger does not allow the child record to be inserted. 

@ Ifthe parent-child relationship is set to “delete prohibit,” delete triggers will not 
allow the deletion of a “parent” record if a “child” record still exists. However, if 
the relationship between a parent and child table has been set to “cascade” delete, 
the delete triggers will automatically delete child records if a parent record is 
deleted. 

@ The update tnggers ensure that the field of a parent record which links it to a child 
record cannot be changed unless the trigger is set to automatically change the 
corresponding field in the child record. 

The stored procedures which calculate the balance of each account are also SQL code. 
These stored procedures are called by triggers. When an event occurs that would change the 
balance of an account, such as the insertion of a travel record (i.e., a travel expense), the 
trigger causes the stored procedure to execute that calculates the travel balance of the 
account to be charged. 

2. Application (Front-end) Processing 

The application handles data validation. In other words, it only allows the user to enter 
data which meets data integrity constraints. For example, the application will not allow the 
user to enter a negative number for the number of days an individual was on travel. Of course 


the application cannot stop the user from entering incorrect data. For example, the user could 


enter that an individual was on travel for five days when they were actually on travel for three 
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days. The application would not catch the incorrect entry because five is in the range of valid 
numbers allowed to be entered in the field. 
B. APPLICATION DEVELOPMENT 
1. Background 
As stated previously, a product called PowerBuilder Desktop was used to develop the 
application (front-end) of the FMS. PowerBuilder is a graphical application development tool 
for developing client/server applications that access databases. PowerBuilder provides pre- 
made standard window controls such as buttons, radiobuttons, checkboxes, dropdown 
listboxes, etc., to minimize the amount of coding that needs to be done by the developer. It 
also provides a scripting language with built-in functions which also help to minimize coding. 
Typically scripts are executed when an event occurs such as when a user clicks on a button. 
A PowerBuilder application is made up of objects such as windows and menus. Objects 
are stored in PowerBuilder libraries and retrieved from these libraries when the application 
istun. Some of the types of PowerBuilder objects are: 
@ Application Object: the entry point into an application which defines application- 
level behavior such as what the default text font is and what processing should be 
done when the application begins or ends. 


® Window Objects: the interface between the application and the user. They request 
information and display information. 


® DataWindow Objects: used for retrieving and manipulating data from a relational 
database or other source such as a spreadsheet. It also determines the style of 
presentation of data such as tabular or freeform. Output from the database such 
as reports are retrieved and displayed using DataWindow objects. 


@ Menus: provides the user of the application with a list of choices (actions) to 
select from such as listing reports that can be produced. 
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@ Global Functions: independent objects that perform general-purpose processing 
such as string handling. 


® Queries: a SQL statement that is used to retrieve data from a relational database 
and saved with a name so that it can be reused. Normally they provide data for a 
DataWindow object. 

@ Structures: a collection of one or more related variables of possibly different data 
types grouped under a single name. This corresponds to the data structure called 
a “record” in Pascal and other programming languages. Structures allow the 
developer to refer to a set of related items as a single unit, rather than having to 


refer to multiple items. 


@ User Objects: an application feature defined by the user so that it can be reused 
in one or more applications. 


@ Libraries: as stated previously, PowerBuilder libraries are used to store objects. 
Applications retrieve the objects from the libraries so libraries can be shared by 
multiple applications. 

@ Projects: packages the application for execution by the application user(s). The 
application can be packaged as a stand-alone executable or as an executable that 
links to PowerBuilder dynamic libraries at execution time. 

2. Implementation 
a. Financial Management System Modules 
The FMS, when complete, will consist of three modules (projects, in 
PowerBuilder terminology) -- a staff module, a faculty module, and a chairman module. The 
purpose of the staff module is to provide the means for the academic department’s 
administrative staff to input data into the system and produce reports. The purpose of the 
faculty module is provide the means for the academic department’s faculty to check the status 


of the research accounts for which they are assigned as the principal investigator. The 


purpose of the chairman module is provide the means for the academic department’s chairman 
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to check the status of all of the department’s accounts and to perform planning and other 
accounting functions unique to the department chair. The staff module was developed as the 
prototype system for this thesis research project. The faculty module is developed but will 


not be discussed in this thesis. 


b. Staff Module Components 

The staff module of the FMS revolves around two main components as reflected 
by the majority of window objects used in the module. These window objects are employee 
related windows and account related windows. For both employees and accounts, there are 
list windows for providing a listing of all records with a minimum of attributes shown, detail 
windows for showing all of the attributes of one record, and search windows for searching 
for a specified employee or account record. From the employee detail window, the user can 
add or modify an employee record. (Note: employee records are normally not deleted. If an 
individual ceases to be a Naval Postgraduate School employee for whatever reason, an 
employment termination date attribute is filled in. If an employee record needs to be deleted 
because it was added in error, the staff member who made the entry asks the database 
administrator to delete the record.) 

A screen shot of the employee detail window is shown in Figure 4. The employee 
detail window shows the accounts (if any) the employee is the principal investigator for. 
Every research account is assigned one or more principal investigators who are responsible 
for overseeing the research and authorizing the expenditure of funds in the research account 


in support of the research. Funding for the account is broken out into the following 
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categories: faculty labor, support labor, OPTAR (equipment), travel, and contracts (broken 
out as MIPR, IPA, and other contracts). 

The account detail window displays details about the account such as the 
expiration date of the account, the account sponsor, and the initial and current balance of the 
account in each of the funding categories. A screen shot of the account detail window is 
shown in Figure 5. 

As can be seen from Figure 5, there is a tab for each general funding category of 
the account. By clicking on a tab, the user can display more details about expenditures in that 
category. Example screen shots of expenditures for the labor, OPTAR, and travel funding 
categories of an account are shown in Figures 6, 7, and 8, respectively. When the user (staff 
member) clicks on a funding category tab, she can then add, modify, or delete records of 
expenditures for that funding category of the displayed account. 

The PowerBuilder objects used by the staff module are stored in seven 
PowerBuilder libraries. The libraries are: 

@ fms_main.pbi. This object contains the main objects for the FMS staff module 
such as the main menu, the main window, the password window for logging in to 
the system, the “about” window which gives version and authorship information 
about FMS, and the toolbar configuration window which allows the user to select 
where to place the toolbar (sometimes known as a buttonbar). The toolbar allows 
the user to readily access employee, account and other windows by clicking on the 
buttons on the toolbar. 

© fms emp.pbl. This object contains employee related objects such as the employee 


detail window, the employee list window, the employee search window, and an 
employee list DataWindow for printing a list of employees. 
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® jfms_acct.pbl. This object contains account related objects such as DataWindows 
for labor, OPTAR, travel, and contract expenditure listings for an account. These 
objects are shared by the faculty module of the FMS. 

@ jms_acc2.pbl. This object contains account related objects used solely by the staff 
module of the FMS such as the account list window, the account detail window, 
and the account search window. 

@ fms_mnt.pbl. This object contains maintenance related objects such as windows 
and DataWindows for adding, modifying or deleting records of labor, OPTAR, 
travel, and contract expenditures and adding, modifying or deleting records of 
sponsors of research accounts. These objects are shared by the faculty module of 
the FMS. 

@ jms _mnt2.pbl. This object contains maintenance related objects used solely by the 
staff module of the FMS such as windows and DataWindows for adding, 
modifying, and deleting employee and account records. 

@ fms rpt.pbl. This object contains report related objects such as DataWindows for 
producing reports on labor, OPTAR, travel, and contract expenditures. 

A complete listing of the objects contained in each PowerBuilder library of the 
FMS staff module is in Appendix D. 

c: Rapid Application Development 

A methodology that was used in developing the FMS staff module is known as 
Rapid Application Development (RAD) [Ref. 9]. This methodology, also known as “Rapid 
Prototyping,’ seeks to speed the development of a system by developing a quick prototype 
of the system, demonstrating the prototype to the eventual users of the system for their input, 
making changes to the system based on the users input, and repeating the cycle until a 
deliverable product is developed [Ref. 10, 11]. As we developed the FMS staff module, we 


demonstrated it every two to four weeks to the Operations Research Department staff 


members who would be using the system. At times, the staff input not only resulted in 
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Changes to the design of the application but also to the design of the database. Fortunately, 
the tools we were using, 5-Designor AppModeler and PowerBuilder Desktop, allowed us to 
make changes to the database design relatively easily and with minimal impact on the 
application. 
C. APPLICATION DEPLOYMENT 

Once the FMS staff module prototype was developed to the point of being usable and 
with no obvious bugs, it was installed in the Operations Research Department for testing and 
debugging. Staff members were given a brief instruction on how to use the system and asked 
to use the system in parallel with existing systems to check the accuracy of the FMS. Staff 
members were also asked to report in writing all bugs they discovered and to request desired 
enhancements to the system in writing. Bug reports were evaluated to determine if an actual 
bug existed or whether the problem was due to operator error. If an actual bug existed, it 
was fixed and the fix was installed as soon as possible. Enhancement requests were evaluated 
to determine if they could reasonably be implemented. If so, the enhancement was made and 
installed. If not, the requester was notified why the requested enhancement could not be 


made to the system. 
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Figure 3. Parent-child Relationship of Employee and Department Tables 
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Figure 4. Employee Detail Window 
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Figure 6. Account Detail Window Showing Labor Expenses 
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Figure 8. Account Detail Window Showing Travel Expenses 
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IV. ANALYSIS 


A. TOOLS 

1. Database Modeling 

The database modeling tool used, S-Designor AppModeler from Powersoft 
Corporation, allows the user to create a graphical representation of some of the components 
of a relational database. This includes tables, table attributes, relationships between tables, 
and views. These components are stored in what S-Designor AppModeler refers to as the 
“physical data model.” Other components of the relational database, such as indexes, 
triggers, and stored procedures, can be created as part of the physical data model using S- 
Designor AppModeler but are not shown in the graphical representation. 

Overall, we found S-Designor AppModeler (hereafter referred to as AppModeler) to 
be a very useful database modeling tool. As with any software tool, it has its strong points 
and weak points. 

a. Strong Points 
@ Overall ease of use. The user interface is fairly simple and straightforward. We 
were able to start using it with only a minimal amount of reading of the User's 
Guide and the on-line help. Sample physical data models were provided which 
also helped with learning how to use AppModeler. For preparing the graphical 
portion of the physical data model, several AppModeler tools are available in a tool 
palette: a table tool, a reference tool (for indicating the relationship between 
tables), a view tool, and so on. These tools in the tool palette make it simple for 
the user to create the tables, relationships, and views that are part of a database. 


A screen shot of AppModeler with the tool palette and the FMS physical data 
model 1s shown in Figure 9. 


Zo, 


e Automatic generation of the database. Once the user has completed a physical 
data model, with the click of the mouse, the database can be generated. The user 
has the option of having AppModeler generate the database, or generate an SQL 
script which can be executed separately to generate the database. Before the 
database or SQL script are generated, AppModeler automatically checks the model 
for correctness. The user can generate the database for any of a number of target 
databases such as Sybase SQL Anywhere and Oracle. Many other options are 
available. A screen shot of the AppModeler database generation screen is shown 
in Figure 10. 


@ Automatic modification of the database. Automatic modification of the database 
is both a strong point and a weak point (see below). To modify the database, the 
user archives the current (prior to the changes) physical data model, makes 
changes to the physical data model, and then selects the Modify Database 
command. The user can choose to modify all tables or specify which tables to 
modify, modify all indexes or specify which indexes to modify, and modify all 
triggers and procedures or specify which triggers and procedures to modify. As 
with the automatic generation of the database, the user can choose to modify the 
database directly or to have an SQL script generated which can be executed 
separately to modify the database. It was very useful to select the option to 
generate the SQL script to check over what AppModeler was going to do to 
modify the database. If it appeared that the script would accomplish the intended 
modification, then the option to directly modify the database was selected. A 
screen shot of the AppModeler database modification screen is shown in Figure 1! 1. 


@ Automatic generation of indexes. Indexes provide an ordered list of the records 
of a table based on a key field. There are two types of key fields, primary and 
foreign. A primary key consists of one or more fields (attributes) that uniquely 
identify a record in a table. A foreign key is a field that depends on and migrates 
from a primary key in another table. With a few mouse clicks, the database 
indexes for key fields (both primary and foreign) can be automatically generated 
or, after modification of the database, regenerated. 


e Ease of creating relationships between tables. As mentioned previously, there is 
a “reference” tool in the AppModeler tool palette for creating relationships 
between tables. The user clicks on the Reference tool in the tool palette, clicks on 
the child table and drags the reference to the parent table. If the foreign key in the 
child table has the same name as the primary key in the parent table, those fields 
are automatically selected for the relationship. The user can specify which fields 
to use for the relationship if the correct fields are not automatically selected. 


e Automatic generation of referential integrity constraint tnggers. AppModeler 
automatically created referential integrity constraint triggers for tables with parent- 


child relationships. In every case, the triggers automatically generated by 
AppModeler worked correctly. 


Ease of creating and modifying tnggers and stored procedures. In order to have 
the balance of the various funding categories of accounts calculated automatically, 
we had to create and modify some triggers and stored procedures. AppModeler 
made this task relatively easy by providing the means to list all tnggers and 
procedures, listing triggers by table, and allowing the user to edit them with a 
simple but adequate text editor. As mentioned previously, once the user had 
created or modified the tigger or stored procedure, he could automatically add it 
to the database or modify it in the database using the automatic modification 
feature of AppModeler. 


Automatic documentation (report) generation. AppModeler can automatically 
generate three types of reports: a full report which contains all main model ttems, 
a standard report which contains physical data model graphics, and all table- 
dependent items, and a list report which contains a single title item and all list-type 
items. User-defined reports can also be created. The user can print the report or 
save it in “Rich Text Format” to a file. Additionally, the user can choose to print 
the physical data model graph in color or black and white and can have 
AppModeler automatically scale the graph so that it fits on one page (an extremely 
useful feature). Part of the AppModeler full report (database schema information) 
for the FMS physical data model is given in Appendix E. 


b. Weak Points 


Automatic modification of the database. If too many changes were attempted at 
once, AppModeler did not have the intelligence to perform them in an order that 
would achieve the desired results and thus end up with a physical data model that 
did not match the actual database. That is why it 1s extremely helpful for the user 
to first have AppModeler generate the SQL script and to check the script before 
having AppModeler directly modify the database. The other problem observed 
was that frequently AppModeler could not perform modification of a key field 
because it did not have the intelligence to perform the necessary steps. Modifying 
a key field usually had to be done manually in several steps. First, the data from 
the table had to be exported to a comma-delimited file. Then the user had to 
delete any relationships with the table and the table itself and use the automatic 
modification feature to implement this on the database. Then the user had to 
recreate the table with the desired change to the key field and recreate the 
relationships for that table and again use the automatic modification feature to 
implement the changes on the database. Finally, the user had to import the data 
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from the comma-delimited file back into the table. On occasion the user had to 
first manipulate the contents of the comma-delimited file (using a spreadsheet or 
other program) to get it into a form that would be accepted by the modified table 
before importing it into the modified table. In other words, the automatic 
modification feature was, at times, dangerous and/or time-consuming. 


@ Graphical representation of the database. This was a weakness in the sense that 
AppModeler could not work with an EER diagram. A preferable method is to 
create and modify an EER diagram and have AppModeler generate the table, 
attributes, relationships, and so on, from that. 

@ Automatic generation of relationships. The automatic generation of relationships 
(references) in AppModeler created a relationship between every primary and 
foreign key with the same name. In our case, this created many relationships that 
were not intended and so we found it far easier to manually create the desired 
relationships using the Reference tool in the tool palette. 

2. Application Development 

The application development tool used was PowerBuilder Desktop from Powersoft 
Corporation. PowerBuilder is a tool for developing graphical client/server applications that 
access relational databases. As such it attempts to minimize the amount of coding done by 
the developer in order to make it easier and faster to develop and maintain the application. 

Overall, we found that PowerBuilder did live up to its stated purpose of easing the 
development and maintenance of an application. Some of its strong and weak points are 
listed here. 

a. Strong Points 

@ Pre-made standard window controls. PowerBuilder made it easy to design menus 
and other standard windowing controls and thus saved a great deal of coding. 

@ Ability of multiple applications to share libraries. Some of the libraries were used 


for multiple modules (projects) of the FMS, which made it much quicker to 
develop the modules and maintain them. 


@ Reusable objects. PowerBuilder objects we created, such as DataWindows, were 
saved in libraries and reused within a module (project) and by multiple modules. 


@ PowerBuilder Painters. Similar to the tool palette of AppModeler, PowerBuilder 
had “painters” for creating PowerBuilder objects such as DataWindows, 
Applications, Projects, Menus, and so on. These painters provided an easy to use 
interface for creating these objects. 


@ Support. PowerBuilder is a fairly widely used product and consequently there 
exists a support forum for it on the computer service called CompuServe. The 
support forum is available at no extra charge for CompuServe subscribers and is 
made up of users of PowerBuilder (not Powersoft employees). On the occasions 
where we ran into problems with PowerBuilder that we could not solve, we posted 
a message detailing the problem on the support forum on CompuServe and 
received an answer usually within twenty-four hours that solved the problem. This 
form of support was important for keeping the cost of the project down since 
technical support from Powersoft is not free. 


b. Weak Points 


@ Difficulty in changing fonts and font sizes. For various reasons, the font and/or 
font size for some of the windows and reports were changed several times. 
Unfortunately there was no means available to make a global change. 
Consequently, each text object had to be changed individually, making it a very 
tedious and time consuming process. 


@ Scripting language awkward. The scripting language is not designed logically. 
Too many features are ad hoc add-ons. 


@ The executable is not truly compiled. It requires the application’s dynamic library 
files in order to work. 


®@ Inadequate documentation. The manual for PowerBuilder was the smallest of the 
manuals for the three programs that made up Powersoft Portfolio. Not only was 
it the smallest but it was also the least adequate. We found it necessary to 
purchase third-party books about PowerBuilder to supplement the manual. 


J 
2 


B. DATABASE SERVER 

The database server used is Sybase SOL Anywhere. Powersoft Portfolio included a 
four-user version of Sybase SOL Anywhere. That means that four individuals can 
concurrently be logged in to the database server (users accessing the FMS application are 
logged in to the database server). This database server, in previous releases, was know as 
Watcom SOL Server. The dialect of SQL implemented by Sybase SOL Anywhere is Watcom- 
SQL. (Note: Every database server implements its own “dialect” of SQL that consist of what 
might be called “standard” SQL plus some extensions to it. It is similar to the various 
implementations of programming languages such as Pascal, BASIC, FORTRAN, and so on, 
by software vendors.) The database server allows a database application to communicate 
with a database over a network and it handles the processing done by the database, 1.e., the 
“back-end” processing of a client/server application. Users must enter a valid user ID and 
password to make a connection (log in) to the database server. The Sybase SOL Anywhere 
server will run on a variety of platforms including: Novell NetWare, Windows 95, Windows 
NT, OS/2, Windows 3.x, and DOS. No matter what platform that Sybase SOL Anywhere is 
running on, it can be accessed by clients operating with different operating systems, such as 
DOS, Windows 95, Macintosh, running on different kinds of networks such as Novell 
NetWare, Windows NT, and Banyan Vines. 

Overall, we were pleased with the Sybase SOL Anywhere database server. Some of its 


strong and weak points are listed here. 


Strong Points 


@ Runs on multiple platforms. At first we ran the database server on a Novell 
NetWare server. During a time period when we were having a problem with the 
database server, occurrence of certain events could cause the database server to 
crash. When trying to recover the database server from the crash, it would 
sometimes cause the Novell server to crash. Because Sybase SOL Anywhere runs 
on a variety of platforms, we were able to move it to mun on a networked PC 
running Windows 95 so that if the database server crashed, it did not affect the 
Novell server. 


@ Ease of use. Sybase SOL Anywhere was very easy to start up and administer. 


@ Support. As with PowerBuilder, a support forum is available on CompuServe for 
Sybase SOL Anywhere that is free for CompuServe subscribers. Also as with 
PowerBuilder, we posted problems we had with Sybase SOL Anywhere on the 
forum and received correct solutions usually within twenty-four hours. 


@ Documentation. Powersoft Portfolio contained three manuals for Sybase SOL 
Anywhere. These included a Watcom-SQL reference that we made good use of 
for writing the stored procedures and triggers for the FMS. These manuals were 
also available on-line so the user can easily search for specific topics. 


Weak Points 


® No automatic backup of the database. When the database server is running, the 
database files are open. Software for tape backup systems cannot backup files that 
are open. We wanted to have regular backups of the database but that meant we 
had to shut down the database server at the end of the workday (the tape backup 
automatically ran at night) and then start it up again at the beginning of the 
workday. It would have been very helpful if the database server could have been 
automatically scheduled to start and stop at specified times. 


®@ Database server crash caused Novell server crash. As mentioned in the strong 
point about Sybase SOL Anywhere running on multiple platforms, for a time we 
had a problem with the database server crashing and, in turn, causing the Novell 
server it was running on to crash. That was very disruptive to the users of the 
Novell server and was totally unsatisfactory. We did receive information via the 
forum on CompuServe on how to fix the problem but we decided to move the 
database server off the Novell server to a PC just to be safe. 


@ Inability to handle a query with many outer joins. The event that caused the 
database server to crash was the execution of a query with many outer joins. This 
problem was a bug that had purportedly been fixed in an earlier release of Sybase 
SQL Anywhere but had apparently been reintroduced into the version we were 
using. The end result was that the queries had to be rewritten without the outer 
joins since Sybase SQL Anywhere could not handle them even though it was 
supposed to be able to do so. 


C. PROTOTYPE 

The FMS prototype was installed in the Operations Research Department for testing 
and debugging in September 1996. As with any new system, many bugs have been 
discovered and a variety of enhancements have been requested but overall, we believe the 
system has been well received. A listing of strong and weak points follow. 


1. Strong Points 


@ Ease ofuse. The users of the FMS were provided with very brief instructions on 
how to log in to the application and do a few simple tasks. They have been able 
to effectively use the system without any additional instruction. 


@ Maintainability. We have been able to make changes to the system to fix bugs and 
to implement enhancement requests with relative ease. Bugs are usually fixed 
within a few hours. Simple enhancement requests have also been completed within 
a few hours but the more complex enhancement requests (ones that involved a 
design change) have taken a couple of days to implement (lapsed time -- the actual 
work took no more than a day per added feature). The ease of maintainability is 
due in large part to the software tools we have been using as discussed earlier in 
this chapter. 


2 Weak Points 


@ Error messages. Due to a lack of time, we have not prepared error messages for 
all of the situations that users can cause errors. In situations where the FMS does 
not trap errors and provide an error message, error messages are generated by the 


Sybase SOL Anywhere database server. Probably the most frequent error the user 
makes 1s to attempt an action that violates referential integrity. The error messages 
produced by the database server in these (and all other) situations are not 
comprehensible to the ordinary user. Instead, the error messages confuse the user 
and discourage him from using the system. We are correcting this deficiency as 
time permits. 


Lack of user generated reports. We have not provided the user with a means to 
generate reports of his own design. The complexities involved in providing such 
a capability to the user dictate that if it 1s implemented, 1t will provide a fairly 
rudimentary report generation capability. It may be possible, however, to train the 
users to utilize a Powersoft product called JnfoModeler to produce reports. One 
of the purposes of /nfoModeler is to provide an easy means for end-users to 
produce reports from a Sybase SOL Anywhere database. 
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V. CONCLUSIONS AND RECOMMENDATIONS FOR FUTURE STUDY 


A. CONCLUSIONS 

The prototype Financial Management System currently deployed in the Operations 
Research Department is nearly a production system which, with some modifications, could 
be used as an accounting system for all the academic departments at the Naval Postgraduate 
School to track their financial accounts. The prototype has demonstrated that even though 
user requirements frequently change, it can be changed to meet new requirements relatively 
quickly and easily. Comparing the EER diagram in Figure 1 to the physical data model in 
Figure 2, it is obvious that the design of the FMS changed a great deal over the course of this 
thesis project. Yet, the majority of changes were implemented within a few a days of the 
decision to change the design. This quick turn-around for implementing design changes 
would not have been possible if this project had been prepared using only a programming 
language such as C++. 

The tools used (those contained in Powersoft Portfolio) were an invaluable part of this 
project and very inexpensive when compared to some of the other tools on the market. That 
is not to say that Powersoft Portfolio is the best client/server application development tool 
set available for those on a tight budget. It did, however, meet the needs of this project and 
we would recommend it for use by others with similar needs and resources. 

Changes and additions need to be made to the FMS. The faculty module has been 
developed but it needs to be deployed for testing and debugging. Error conditions in the staff 


module need to be trapped and clear error messages displayed when errors occur. An on-line 
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help system needs to be added and the users need to be able to easily produce rudimentary 
reports from the data available. These changes and additions can be made to the system 
relatively easily using the tools we have available when time permits. 
B. RECOMMENDATIONS FOR FUTURE STUDY 

The system could be extended to become an automated aid for the academic 
departments. By extending the database and the application, the system could be used for 
property management, scheduling classes, and managing other databases used by the 
departments. This would prevent the same data from being entered multiple times into 
separate databases. For example, accountable property is tagged with a minor or plant 
property tag and entered into a database with various attributes about each piece of property. 
Much of this property is purchased by academic departments from their various accounts and 
many of the same attributes about this property are stored in the FMS table called 
OPTAR_ REQ as are stored in the property database. Since the FMS is a relational database, 
it could be made to interface with this property database, i.e., have relationships created with 
a modified form of the property database tables. Another relation could be created for 
property that was maintained by staff members at the school, such as computer hardware, so 
those staff members could keep a record of maintenance performed on the property. Other 
existing systems at the Naval Postgraduate School such as SACONS (Standard Automated 
Contracting System) could also be made to interface with the FMS to further reduce multiple 
entries of the same data and other problems associated with having separate databases that 


contain essentially the same information. In fact, these existing systems should also be 
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analyzed for possible changes to maximize the benefits available through the use of 
client/server database applications. 

A “chairman’s” module still needs to be developed for the FMS to assist the academic 
department chairman in planning the expenditure of funds, especially at the beginning of each 


fiscal year. 


A course information database would be another useful addition to the FMS. It could 
be used to relate planned instruction (courses) to the expenditure of funds for supplies and 


labor needed to support instruction. 
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APPENDIX B. FMS DATABASE TRIGGERS 


oe 


ew ww wr ww a mw tn ww ets me ae i ei el 
Cl en ee ee ee 


Database name: FMS 
DBMS name: Watcom SOL 4.0 
Created on: 2/3/97 4:520EM 


do gO oO oo? 
cP 6? 


oo? 


% Before insert trigger “tib account” §for Table 22CcounT 
create trigger tib account before insert on ACCOUNT 
referencing new as new_ins for each row 
begin 
declare user defined exception exception for SQLSTATE '99999'; 
declare found integer; 
% Parent "SPONSOR" must exist when inserting a child in "ACCOUNT" 
if (new_ins.SPON ID CODE is not null) then 
begin 
set found = 0; 
select 1 
MHEO  LOunG 
from dummy 
where exists (select 1 
from SPONSOR 
where SPON_ID CODE = new_ins.SPON_ID CODE); 
if found <> 1 then 
signal user defined exception 
end if; 
end 
end if; 
end 


/ 


% After insert trigger "tia_account”" for table "ACCOUNT" 
create trigger tia_account after insert on ACCOUNT 
referencing new as new_ins for each row 
begin 

call CALC_BAL CONTRACT (new_ins.JON,'M'); 

call CALC BAL CONTRACT (new_ins.JON,'I"); 

call CALC BAL CONTRACT (new_ins.JON, '0'); 

call CALC BAL FAC LABOR(new_ins.JON) ; 

call CALC BAL SPT LABOR(new_ins.JON); 

call CALC BAL OPTAR(new_ins.JON) ; 

call CALC BAL TRAV(new_ins.JON); 
end 


/ 


% Update trigger "tua_account" for table "ACCOUNT" 

create trigger tua_account after update of INIT _FAC_ LABOR §, 
INIT SPT LABOR _S, 
INIT TRAVEL S$, 
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INIT OPTAR $, 
INIT CONT MIPR, 
INIT CONT IPA, 
INIT CONT OTH 
on ACCOUNT —_ 3 
referencing new as new_upd old as old _upd for each row 
begin 
declare user defined exception exception for SOLSTATE '99999"; 
declare found integer; 
call CALC_BAL CONTRACT(new_upd.JON,'M'); 
call CALC_BAL CONTRACT(new_upd.JON, 'I'); 
call CALC_BAL CONTRACT(new_upd.JON,'0O'); 
call CALC BAL FAC LABOR(new_upd.JON); 
call CALC_BAL SPT LABOR(new_upd.JON) ; 
call CALC BAL OPTAR(new_upd.JON); 
call CALC BAL TRAV(new_upd.JON); 
end 


/ 


% Before insert trigger “tib adp proj info” for table) "ADERrEe aie. 
create trigger tib adp proj info betore insert on ADP PRe Jenin 
referencing new as new_ins for each row 
begin 
declare user defined exception exception for SOLSTAIS | 27274, 
declare found integer; 


% Parent "DEPARTMENT" must exist when inserting a child in 
"ADP_PROJ_ INFO" 
if (new_ins.DEPT CODE is not null) then 
begin 
set found = 0; 
select 1 
inte, found 
from dummy 
where exists (select 1 
from DEPARTMENT 
where DEPT CODE = new_ins.DEPT CODE); 
if found <> 1 then 
signal user detined exceprer1on 
end if; 
end 
end if; 


% Parent "EMPLOYEE" must exist when inserting a child in 
“ADP PROJ INFO" 
if (new_ins.PROJ_MGR_CODE is not null) then 
begin 
set found = QO; 
select 1 
into found 
from dummy 
where exists (select 1 
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from EMPLOYEE 
where EMP _ID_CODE = new_ins.PROJ_MGR CODE); 
if found <> 1 then 
Signal user defined exception 
end ict * 
end 
end isi; 


% Parent “EMPLOYEE" must exist when inserting a child in 
“ADP PROJ INFO" 
if (new_ins.POC_ CODE is not null) then 
begin 
set found = QO; 
select 1 
into found 
from dummy 
where exists (select 1 
from EMPLOYEE 
where EMP_ID CODE = new_ins.POC CODE); 
if found <> 1 then 
Signal user defined exception 
end if; 
end 
end if; 
end 


/ 


%* Before insert trigger “tib contracts" for table “CONTRACTS” 
create trigger tib contracts before insert on CONTRACTS 
referencing new as new_ins for each row 
begin 
declare user defined exception exception for SQLSTATE '99999'; 
declare found integer; 


% Parent "ACCOUNT" must exist when inserting a child in "CONTRACTS" 
1£ (new_ins.JON is not null) then 
begin 
set found = 0; 
select l 
It Ose found 
from dummy 
where exists (select l 
from ACCOUNT 
where JON = new_ins.JON); 
if found <> 1 then 
Signal user defined exception 
end if; 
end 
end i1t- 


% Parent "EMPLOYEE" must exist when inserting a child in "CONTRACTS" 
if (new_ins.REQUESTER is not null) then 
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begin 
set found = 0; 
select 1 
into found 
from dummy 
where exists (select 1 
from EMPLOYEE 
where EMP_ID_ CODE = new_ins.REQUESTER) ; 
1f found <> 1 then 
Signal user defined exception 
end if; 
end 
end if; 
end 


/ 


@epAtter insert trigger "tia contracts” for Eablew Conia ers, 
create trigger tia _ contracts after insert on CONTRACTS 
referencing new as new ins for each row 
begin 

declare user defined exception exteption for ™SOLSTATE” Jove7. 


call CALC BAL CONTRACT (new_ins.JON,new_ins.CONTRACT TYPE) 


end 


/ 


* Before update trigger “tub contracts" for table "CONTRACTS" 
create trigger tub contracts before update of JON, 
CONTRACT TYPE, 
REQUESTER, 
Doc # 
on CONTRACTS 
referencing new as new_upd old as old_upd for each row 
begin 
declare user defined exception exception for SQLSTATE '99999'; 
declare found integer; 


% Parent "ACCOUNT" must exist when updating a child in "CONTRACTS" 
if (new_upd.JON is not null and 
((old_upd.JON is null) or 
(new_upd.JON <> old _upd.JON))) then 
begin 
set found = 0; 
select 1 
into found 
from dummy 
where exists (select 1 
from ACCOUNT 
where JON = new_upd.JON); 
if found <> 1 then 
Signal user defined exception 


a2 


end if; 
end 
end if; 


% Parent "EMPLOYEE" must exist when updating a child in "CONTRACTS" 
if (new_upd.REQUESTER is not null and 
((old_upd.REQUESTER is null) or 
(new_upd.REQUESTER <> old _upd.REQUESTER))) then 
begin 
set found = 0; 
select 1 
inte fLound 
from dummy 
where exists (select 1 
from EMPLOYEE 
where EMP ID CODE = new_upd.REQUESTER) ; 
if found <> 1 then 
Signal user defined exception 
end if; 
end 
end if; 


% Cannot modify parent code of "EMPLOYEE" in child "CONTRACTS" 
if ((new_upd.REQUESTER is null and old_upd.REQUESTER is not null) or 
new_upd.REQUESTER <> old _upd.REQUESTER ) then 
Signal user defined exception 
end if; 
end 


/ 


* Update trigger “tua_contracts" for table "CONTRACTS" 
create trigger tua_contracts after update of JON, 
CONTRACT TYPE, 
CONTRACTOR_ID, 
PROJ COST, 
ACTUAL COST 
on CONTRACTS 
referencing new as new_upd old as old _upd for each row 
begin 
declare uservdefined exception exception for SOBSTATE "99999"; 
declare found integer; 


call CALC_BAL CONTRACT (new_upd.JON,new_upd.CONTRACT TYPE) 


end 


/ 


56 After delete trigger “tda Contracts” for stable contacts: 
create trigger tda_contracts after deletewen CONTRACcTs 
referencing old as old del for each row 

begin 


3) 


declare user defined exception exception for SQLSTATE '99999'; 
declare found integer; 


call CALC_BAL_CONTRACT(old_del.JON,old_del.CONTRACT TYPE) 


end 


/ 


°. 


ey Before insert trigger “Cb employee” for Cable) EMPLOYEE. 
create trigger tib employee before insert on EMPLOYEE 
referencing new as new_ins for each row 
begin 
declare user defined exception exception for SQLSTATE '99999'; 
declare found integer; 
% Parent "DEPARTMENT" must exist when inserting a child in "EMPLOYEE" 
if (new_ins.DEPT CODE is not null) then 
begin 
set found = 0; 
select 1 
imtoo found 
from dummy 
where exists (select 1 
from DEPARTMENT 
where DEPT CODE = new_ins.DEPT CODE); 
if found <> 1 then 
Signal user_defined exception 
Gendt; 
end 
endant-; 
end 


/ 


is) 


% Before insert trigger "tib faculty” for table "FACULTY" 
€reate trigger tib faculty be@ere insert on FAGULG 
referencing new as new_ins for each row 
begin 
declare user defined exception exception for SQLSTATE '99999'; 
declare found integer; 
% Parent "EMPLOYEE" must exist when inserting a child in “FACULTY" 
if (new_ins.EMP ID CODE is not null) then 
begin 
set found = Q; 
select 1 
unico found 
from dummy 
where exists (select 1 
from EMPLOYEE 
where EMP ID CODE = new_ins.EMP_ID_ CODE); 
if found <> 1 then 
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Signal user defined exception 
end if; - 
end 
end if; 
end 


/ 
* Before insert trigger "tib labor chgs" for table "LABOR CHGS" 
create trigger tib labor _chgs before insert on LABOR _CHGS 
referencing new as new_ins for each row 
begin 
declare user_defined_exception exception for SQLSTATE '99999'; 
declare found integer; 


% Parent "LABOR LES" must exist when inserting a child in 
"LABOR_CHGS”" 
if (new_ins.EMP ID CODE is not null and 
new_ins.PPE DATE is not null) then 
begin 
set found = 0; 
select l 
iit Ome Guna 
from dummy 
where exists (select 1 
from LABOR_LES 
where EMP ID CODE = new_ins.EMP_ID CODE 
and PPE DATS = newsins. PPEMPALE), 
if found <> 1 then 
Signal user defined exception 
end if; 
end 
end if; 


%* Parent "ACCOUNT" must exist when inserting a child in "LABOR_CHGS” 
if (new_ins.JON is not null) then 
begin 
set found = 0; 
select 1 
into found 
from dummy 
where exists (select 1 
from ACCOUNT 
where JON = new_ins.JON); 
if found <> 1 then 
Signal user _defined exception 
end if; 
end 
end if; 


% Parent "EMPLOYEE" must exist when inserting a child in "LABOR CHGS" 


if (new_ins.EMP ID CODE is not null) then 
begin 
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set found = 0; 
select 1 
InMeGe Lound 
from dummy 
where exists (select 1 
from EMPLOYEE 
where EMP_ID_ CODE = new_ins.EMP_ ID CODE); 
Lf *feunde<> 1 then 
Signal user defined exception 
end if; 
end 
end” it? 
end 


/ 


+ After insert trigger “tia laboryehgs” £65 cable (2a EoR Coca. 
create trigger tia labor chgs after insert on LABOR CHGS 
referencing new as new_ins for each row 
begin 

Gecllare user defined exceptionsexception for SOLSTATE 939 99", 

declare found integer; 

declare emp cat char(1); 

declare joneeype Char(Z); 

declare base sal numeric(10,2); 

declare hourly rate numeric (7,2)% 

Geclare hourly ot rate numerse( ie; 

declare otm_cap numeric(7,2); 

declare yr hrs integer; 

declare rr_ot_ fac numeric(6,4); 

deGiawessal ert Gabe; 

declare acc rate decimal(3,2); 


select OT CAP into otm_cap from, EMS CEG; 
select YR_LABOR HRS into yr_hrs from FMS_CFG; 
select RR OT RARE FACT into am of fac fromeBMS CFG; 


Calculate the "TOTALCHG" field 
if (new_ins.EMP ID CODE is not null) then 
begin 
set found=0; 
select 1 
intGe £Ounad 
from dummy 
where exists (select 1l 
from EMPLOYEE 
where EMP_ID CODE=new_ins.EMP_ID CODE); 


select EFF SAL DATE nto sal eff from EMPLOYEE 
where new _ins.EMP ID CODE=EMPLOYEE.EMP ID CODE; 


if (new_ins.PPE DATBy>= sal eff) then 
begin 
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select BASE SALARY into base sal from EMPLOYEE 
where new_ins.EMP_ID CODE=EMPLOYEE.EMP ID CODE; 
select ACCEL RATE into acc rate from EMPLOYEE 
where new_ins.EMP_ID CODE=EMPLOYEE.EMP ID CODE; 
end 
else 
begin 
select BASE SALARY into base sal from SALARY HISTORY 
where new_ins.EMP_ID_CODE=SALARY_HISTORY.EMP ID CODE 
and new_ins.PPE DATE >= SALARY HISTORY.BEGIN DATE 
and new_ins.PPE DATE <= SALARY HISTORY.END DATE; 
select ACCEL RATE into acc_rate from SALARY HISTORY 
where new_ins.EMP_ID CODE=SALARY_HISTORY.EMP ID CODE 
and new_ins.PPE DATE >= SALARY HISTORY.BEGIN DATE 
and new_ins.PPE DATE <= SALARY _HISTORY.END DATE; 
end 
end if; 


set hourly rate=base sal/yr_hrs; 


Lf W@(houmly rate*i-5) > otm_cap) then 
set hourly ot _rate=-otm_cap 
else 
set hourly ot _rate=hourly rate*1.5 
end 1£; 


select FUND TYPE into jon_type from ACCOUNT 
where new_ins.JON=ACCOUNT.JON; 


select CATEGORY into emp_cat from EMPLOYEE 
where new_ins.EMP ID CODE=EMPLOYEE.EMP_ID_ CODE; 


if (jon_type='RR') then 
begin 
IF (enp cet— Ff) =then 
update LABOR_CHGS, EMPLOYEE 
set TOTAL CHG=(HOURS*hourly rate*acc_ rate) 
where LABOR CHGS.EMP_ID CODE=new_ins.EMP_ ID CODE 
and LABOR CHGS.PPE DATE=new_ins.PPE_DATE 
and LABOR_CHGS.JON=new_ins.JON 
and new_ins.EMP ID _CODE=EMPLOYEE.EMP_ID_ CODE 
else 
if (emp_cat='S") then 
update LABOR_CHGS, EMPLOYEE 
set TOTAL CHG=(HOURS*hourly rate*acc_rate)+t 
(OT HOURS*hourly ot_rate*rr_ot_fac) 
where LABOR CHGS.EMP_ID CODE=new_ins.EMP_ID CODE 
and LABOR CHGS.PPE_DATE=new_ins.PPE_ DATE 
and LABOR CHGS.JON=new_ins.JON 
and new _ins.EMP ID CODE=EMPLOYEE.EMP_ID CODE 
end if 
end if 


my! 


end 
else 


begin 


if (emp cat='F') then 
update LABOR CHGS 


set TOTAL CHG=(HOURS*hourly rate) 


where LABOR_CHGS.EMP_ID_CODE=new_ins.EMP ID CODE 


and LABOR_CHGS.PPE_DATE=new_ins.PPE DATE 
and LABOR CHGS.JON=new_ins.JON 


else 
if (emp_cat='S"') then 


update LABOR CHGS 
set TOTAL CHG=(HOURS*hourly rate)+ 
(OT_HOURS*hourly ot _ rate) 


where LABOR_CHGS.EMP_ID_CODE=new_ins.EMP ID CODE 


and LABOR _CHGS.PPE DATE=new_ins.PPE DATE 
and LABOR _CHGS.JON=new_ins.JON 


end if 
end if 


end 


end if; 


if (emp_cat='F') then 
call CALC_BAL FAC _LABOR(new_ins.JON) 


else 


if (emp cat='S@r then 
call CALC BAL SPT LABOR(new_ins.JON) 
end if 
end if; 


1£ (found <> 1) then 
signal user defined exception 
end if; 


end 
end if; 
end 


i 


% Update trigger "tua labor _chgs" for table "LABOR CHGS" 
create trigger tua_labor chgs after update of EMP ID CODE, 


PPE DATE, 
JON, 
HOURS, 

OT HOURS 


on LABOR CHGS 
referencing new as new_upd old as old_upd for each row 


begin 
declare 
declare 
declare 
declare 
declare 


USer cer ined except 1on exception for SQLSTATE ‘99999'; 
found integer; 

emp cal Clieia( 2); 

JON type char (2); 

base sal numeric(10,2); 
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declare 
declare 
declare 
declare 
declare 
declare 
declare 


hourly rate numeric (7,2); 
hourly ot rate numerre(772)— 
OEM cap numerie( 7,2); 

yr_ hrs integer; 

rr ot fac»numeric(674); 
sale tteaace, 

alee rate decimal( 372); 


select OT_CAP into otm_cap from FMS CFG; 
select YR_LABOR_HRS into yr_hrs from FMS_CFG; 
Solectenk (OT RATE FACT Into rr lecu face = romentome na. 


Calculate the "TOTALCHG" field 
if ((new_upd.HOURS<>old_upd.HOURS) or 
(new_upd.OT_ HOURS<>old_upd.OT _HOURS)) then 


begin 


set found=0; 
select 1l 
TnecomLouna 
from dummy 
where exists (select 1 
from EMPLOYEE 
where EMP ID CODE=new_upd.EMP ID CODE); 


select EFF SAL DATE nto Sate from EMPLOYEE 
where new_upd.EMP ID CODE=EMPLOYEE.EMP_ ID CODE; 


if (neéw_upd.PPE DATE >= sal _ eff) then 


begin 


select BASE SALARY into base sal from EMPLOYEE 
where new_upd.EMP ID CODE=EMPLOYEE.EMP ID CODE; 

select ACCEL RATE into acc rate from EMPLOYEE 
where new_upd.EMP_ ID CODE=EMPLOYEE.EMP ID CODE; 


end 
else 
begin 


select BASE SALARY into base sal from SALARY HISTORY 
where new _upd.EMP ID CODE=SALARY_HISTORY.EMP_ID_ CODE 
and new_upd.PPE DATE >= SALARY HISTORY.BEGIN DATE 
and new_upd.PPE DATE <= SALARY HISTORY.END_DATE; 
select ACCEL RATE into acc_rate from SALARY HISTORY 
where new_upd.EMP ID CODE=SALARY HISTORY.EMP ID CODE 
and new_upd.PPE DATE >= SALARY HISTORY.BEGIN DATE 
and new upd.PPE DATE <= SALARY _HISTORY.END DATE; 
end 
end if; 


set hourly rate=base_sal/yr_hrs; 


1£ ((hourly rate*i-3) > otm cap)e eiem 
set hourly ot_rate=otm_cap 
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else 
set hourly ot _rate=hourly rate*1.5 
end -1f£> 


select FUND TYPE into jon_type from ACCOUNT 
where new_upd.JON=ACCOUNT. JON; 


select CATEGORY into emp cat from EMPLOYEE 
where new_upd.EMP_ID CODE=EMPLOYEE.EMP ID CODE; 


hEnoietyvpe— RR )sst nen 
begin 
if (emp _cat='F') then 
update LABOR_CHGS, EMPLOYEE 
set TOTAL CHG=(HOURS*hourly rate*acc rate) 
where LABOR _CHGS.EMP_ID CODE=new_upd.EMP ID CODE 
and LABOR _CHGS.PPE DATE=new_upd.PPE DATE 
and LABOR _CHGS.JON=new_upd.JON 
and new_upd.EMP_ID_ CODE=EMPLOYEE.EMP ID CODE 
else 
TE (emprecat— Ss 9) tnen 
update LABOR_CHGS , EMPLOYEE 
set TOTAL CHG=(HOURS*hourly rate*acec rate)+ 
(OT HOURS*hourly ot rate*re oc fac, 
where LABOR_CHGS.EMP ID CODE=new_upd.EMP ID CODE 
and LABOR_CHGS.PPE DATE=new_upd.PPE DATE 
and LABOR CHGS.JON=new_upd.JON 
and new_upd.EMP_ ID CODE=EMPLOYEE.EMP ID CODE 
end if 
end if 
end 
else 
begin 
if (emp _cat='F') then 
update LABOR_CHGS 
set TOTAL CHG=(HOURS*hourly rate) 
where LABOR_CHGS.EMP_ID_CODE=new_upd.EMP_ID_CODE 
and LABOR CHGS.PPE DATE=new_upd.PPE_ DATE 
and LABOR_CHGS.JON=new_upd.JON 
else 
if (emp cat="S*) then 
update LABOR_CHGS 
set TOTAL CHG=(HOURS*hourly rate)+ 
(OT HOURS*hourly ot _ rate) 
where LABOR _CHGS.EMP ID CODE=new_upd.EMP_ID_ CODE 
and LABOR_CHGS.PPE DATE=new_upd.PPE DATE 
and LABOR CHGS.JON=new_upd.JON 
end if 
end if 
end 
end if; 
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if (emp _cat='F') then 
call CALC_BAL FAC LABOR(new_upd. JON) 
else 
if (emp_cat='S') then 
call CALC BAL SPT LABOR(new_upd.JON) 
end if 
end if; 


if (found <> 1) then 
Signal user defined exception 
ena if; 
end 
end if; 
end 


| 


% After delete trigger "tda_labor_chgs" for table "LABOR_CHGS" 
create trigger tda_labor_chgs after delete on LABOR CHGS 
referencing old as old del for each row 
begin 
declare user defined exception exception for SQLSTATE '99999'; 
Geclare found integer; 
declare empeycat char(i}, 


select CATEGORY into emp_cat from EMPLOYEE 
where old del.EMP ID CODE=EMPLOYEE.EMP ID CODE; 


if (emp_cat='F"') then 
call CALC BAL FAC _LABOR(old_ del.JON) 


elseif (emp_cat='S') then 
call CALC_BAL SPT LABOR(old_ del.JON) 
end if; 
end 


/ 


% Before insert trigger "“tib labor les" for table "LABOR LES" 
ereate trigger tib labor’ les before insert on LABORGEES 
referencing new as new_ins for each row 
begin 
declare user_defined_exception exception for SQLSTATE '99999'; 
declare found integer; 


% Parent "EMPLOYEE" must exist when inserting a child in "LABOR_LES" 
if (new_ins.EMP ID CODE is not null) then 
begin 
set found = 0; 
select 1 
inte, found 
from dummy 
where exists (select 1 


6] 


from EMPLOYEE 
where EMP ID CODE = new ins.EMP ID CODE); 
if found <> 1 then — 7 ea 
Signal user defined exception 
end ii; 
end 
end: 1; 
end 


/ 


a) Before sincere striggeéms Cib military “forstao!) ceili pans 
ereate trigger tib military before insert on MILITARY 

referencing new as new_ins for each row 

begin 

declane user defined Exception exception for SsObstTAle 9777250, 
declare found integer; 


% Parent "EMPLOYEE" must exist when inserting a child in "MILITARY" 
if (new_ins.EMP_ID CODE is not null) then 
begin 
set found = 0; 
select 1 
INeoO wy LOuUna 
from dummy 
where exists (select 1l 
from EMPLOYEE 
where EMP _ID CODE = new_ins.EMP_ ID CODE); 
ae found <> 1) then 
signal user defined exception 
end if; 
end 
end if; 
end 


/ 


% Before insert trigger “tib optar_req" for table "“OPTAR_REQ" 
Create trigger tib_optar_ reg before insert on OPTAR REO 
referencing new as new_ins for each row 
begin 
declare user defined exception exception for SQLSTATE ‘'99999'; 
declare found integer; 


% Parent "EMPLOYEE" must exist when inserting a child in "“OPTAR_REQ" 
if (new_ins.EMP ID_CODE is not null) then 
begin 
set found = Q; 
select 1 
into found 
from dummy 
where exists (select 1 
from EMPLOYEE 
where EMP_ID CODE = new_ins.EMP_ID CODE); 
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if found <> 9leenen 
Signal user defined exception 
end if; 7 
end 
end if; 


% Parent “ACCOUNT" must exist when inserting a child in "OPTAR REQ" 
if (new_ins.JON is not null) then 7 
begin 
set found = 0; 
select 1 
Ineo. found 
from dummy 
where exists (select 1 
from ACCOUNT 
where JON = new_ins.JON); 
if found <> 1 then 
Signal user defined exception 
end if; 
end 
end if; 


% Parent “ADP PROJ INFO" must exist when inserting a child in 
"OPTAR_REQ" 
if (new_ins.ADP PROJ # is not null) then 
begin 
set found = 0; 
select 1 
into found 
from dummy 
where exists (select 1 
from ADP_PROJ_INFO 
where ADP PROJ # = new_ins.ADP_ PROJ #); 
if found <> 1 then 
Stance user Cetimed €xXCepercn 
end if; 
end 
end if; 
end 


/ 


%* After insert trigger "tia _optar req" for table "“OPTAR_REQ" 
create trigger tia optar req after insert on OPTAK REO 
referencing new as new_ins for each row 
begin 

declare user defined exception exception for SQLSTATE '99999'; 


call CALC BAL OPTAR(new_ins-.JON) ; 


end 


/ 


% Update trigger "tua_optar req" for table "OPTAR REQ" 
create trigger tua_optar_ req after update of JON, a 
EMP_ID_ CODE, 
Doc #, 
PROJ COST, 
ACTUAL COST, 
ADP PROJ # 
on OPTAR REQ _ 
referencing new as new upd old as old upd for each row 
begin = 7 
Gdeciare user defined exception exception for SQ@LSTATS “999¢ur; 
declare found integer; 


call CALC BAL OPTAR(new upd.JON); 


end 


/ 


= After delete trigger “tda_ optar req" for table "OPTAR REQ” 
create trigger tda optar req after delete on OPTAR REO 
referencungquaid as oldedel for each row 
begin 
declare user defined exception exception for SOLSTATES 9S 777s 
declare found integer; 


call CALC BAL OPTAR(old del.JON); 


end 


/ 


je Before insert triggers tib other eave” for table OTHER EEA Er. 
Create trigger tib other leave before insert on G@aeh yee E 
referencing new as new _ins for each row 
begin 
declare user defined exception exception for SOQLSTATE '99999"; 
declare found integer; 


% Parent "LABOR LES" must exist when inserting a child in 
“OTHER LEAVE" 
if (new_ins.EMP ID CODE is not null and 
new_ins.PPE DATE is not null) then 
begin 
set found = 0; 
select 1 
into found 
from dummy 
where exists (select l 
from LABOR LES 
where EMP ID CODE = new_ins.EMP ID CODE 
and PEE DATE — new_ins.PPE DATE); 
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if found <> 1 then 
Signal user defined exception 
end af 
end 
end if; 


% Parent "“OTHER_LV TYPE" must exist when inserting a child in 
“OTHER LEAVE" 
if (new_ins.TYPE is not null) then 
begin 
set found = 0; 
select 1 
into found 
from dummy 
where exists (select 1 
from OTHER_LV_TYPE 
where OTHER LV TYPE CODE = new ins.TYPE); 
if found <> 1 then 
Signal user defined exception 
endif; 
end 
end af; 
end 


/ 


mm Before update trigger "tub other leave” for table “OTHER LEAVE” 
create trigger tub other leave before update of EMP ID CODE, 
PPE DATE, 
TYE 
on OTHER LEAVE 
referencing new as new_upd old as old _upd for each row 
begin 
declare user defined exception exception for SQLSTATE '99999'; 
declare found integer; 


% Parent "LABOR_LES" must exist when updating a child in 
"OTHER_LEAVE" 
if (new_upd.EMP ID CODE is not null and 
new_upd.PPE DATE is not null and 
((old_upd.EMP ID CODE is null and 
oldeupdePPE DATE iS snuldy) or 
(new_upd.EMP ID CODE <> old_upd.EMP_ ID _CODE or 
new_upd.PPE DATE <> old _upd.PPE DATE))) then 
begin 
set found = 0; 
select 1 
Into. found 
from dummy 
where exists (select 1 
from LABOR LES 
where EMP_ID_CODE = new_upd.EMP ID CODE 
and PPE DATE = new_updiaePr DATE); 


65 


if found <> 1 then 
Signal user _defined_ exception 
end Tf > 
end 
end if; 


% Parent “OTHER LV TYPE” must €xiSt whem Updating 9a. chvldaem 
“OTHER LEAVE" 
if (new_upd.TYPE is not null and 
(Cola supadeTYPE is null) “or, 
(new_upd.TYPE <> old upd.TYPE))) then 
begin 
set found = 0; 
select l 
Meo ~fLound 
from dummy 
where exists (select 1 
from OTHER_LV_TYPE 
where OTHER_LV TYPE CODE = new_upd.TYPE); 
if found <> 1 then 
Srgna Pause n. Germned scxCcepe lon 
end if; 
end 
end 2 > 


% Cannot modify parent code of “OTHER LV TYPE” in child “GTHERP LEAVE, 
if ((new_upd.TYPE is null and old _upd.TYPE is not null) or 
new_upd.TYPE <> old_upd.TYPE ) then 
Signal user defamed exception 
end if; 
end 


/ 


PeCCLOremInsert trigger Ytib prletor Eaeic gray 

ereate trigger tib pi before insert on PI 

referencing new as new_ins for each row 

begin 
declare user defined_exception exception for SQLSTATE '99999'; 
declare found integer; 


% Parent "EMPLOYEE" must exist when inserting a child in "PI" 
TEV (newrins,EMP 1D CODE is nocmiicellyesenen 
begin 
set found = 0; 
select 1 
ito. found 
from dummy 
where exists (select 1 
from EMPLOYEE 
where EMP ID CODE = new_ins.EMP_ID_ CODE); 
if found <> 1 then 
Signal user _defined exception 
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endmirt.- 
end 
end if; 


% Parent “ACCOUNT” must exist when inserting a child in "PI" 
if (new_ins.JON is not null) then 
begin 
set found = 0; 
select l 
into found 
from dummy 
where exists (select 1 
from ACCOUNT 
where JON = new_ins.JON); 
if found <> 1 then 
Signal user defined exception 
end if; 
end 
end if; 
end 


/ 


° 


* Before insert trigger "tib) salary history ™forgtable "“SAEARY HISTORY 
create trigger tib salary history before insert on SALARY HISTORY 
referencing new as new_ins for each row 

begin 

declare user defined exception exception for SQLSTATE '99999'; 
declare found integer; 


% Parent "EMPLOYEE" must exist when inserting a child in 
"SALARY HISTORY" 
if (new_ins.EMP_ ID CODE is not null) then 
begin 
set found = 0; 
select 1 
into found 
from dummy 
where exists (select 1 
from EMPLOYEE 
where EMP ID CODE = new_ins.EMP_ID_CODE); 
if found <> 1 then 
Signal user defined _ exception 
end if; 
end 
end if; 
end 


/ 


% Before insert trigger "tib_ staff" for table "STAFF" 
create trigger tib staff before insert on STAFF 
referencing new as new_ins for each row 


begin 
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declare user defined exception exception for SQLSTATE '99999'; 
declare found integer; 


% Parent "EMPLOYEE" must exist when inserting a child in "STAFF" 
if (new_ins.EMP ID CODE is not null) then 
begin 
set found = O; 
select 1 
totom. found 
from dummy 
where exists (select 1 
from EMPLOYEE 
where EMP_ID CODE = new_ins.EMP ID CODE); 
it etound <> 1 then 
Sagnal user defined exception 
end if; 
end 
end if; 
end 


/ 


% Before insert trigger "tib travel" for table "TRAVEL" 

create trigger tib travel before insert on TRAVEL 

referencing new as new_ins for each row 

begin 
Geclavei usem defined exception exception fom SOlsiIAte 29792 2m, 
declare found integer; 


% Parent "ACCOUNT" must exist when inserting a child in "TRAVEL" 
if (new_ins.JON is not null) then 
begin 
set found = 0; 
select 1 
tno LOund 
from dummy 
where exists (select 1 
from ACCOUNT 
where JON = new_ins.JON); 
2f found <> 1 then 
Signal user defined_exception 
end if; 
end 
end if; 
end 


/ 


% After insert trigger “tia_travel" for table "TRAVEL" 
Create Erigger tia travel after insert on TRAVEL 
referencing new as newins foreach row 
begin 
declare user defined exception exception for SQLSTATE '99999'; 
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call CALC BAL TRAV(new_ins.JON); 


end 


/ 


* Update trigger "tua travel" for table "TRAVEL" 
Create trigger tua travel after update of TO#, 


PROJ COST, 
ACTUAL _COST, 
JON 

on TRAVEL 

referencing new as new_upd old as old_upd for each row 

begin 


declare user defined exception exception for SOLSTATE '99999'; 
declare found integer; 


call CALC BAL TRAV(new_upd.JON); 


end 


/ 


=) After delete trigger “tda travel" for table "TRAVEL™ 

ereate trigger tda travel after delete on TRAVEL 

referencing old as old del for each row 

begin 
declare user defined exception exception for SOLSTATE *99999'; 
declare found integer; 


call CALC BAL TRAV(old_del.JON); 


end 


/ 


® Before insert trigger “tib travel requests” for table “TRAVEL REQUESTS” 
create trigger tib travel requests before insert on TRAVEL REQUESTS 
referencing new as new_ins for each row 
begin 
declare user _defined_exception exception for SQLSTATE '99999'; 
declare found integer; 


% Parent "TRAVEL" must exist when inserting a child in 
"TRAVEL REQUESTS" 
if (new_ins.TO# is not null) then 
begin 
set found = 0; 
select 1 
into found 
from dummy 
where exists (select 1 
from TRAVEL 
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where TO# = new_ins.TO#); 
if found <> 1 then 
SigiameuSseL Cetined Exception 
end if; 
ene! 
end if; 
end 


’ 
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APPENDIX C. FMS DATABASE STORED PROCEDURES 


OA IC ICC ICCC ICCC ICI A I A A A A 9 A A ACCC ef ok i i eee a AC a O/ 


% Procedure CALC BAL CONTRACT 
OL FELLA EE EE LEE EE ERE E EEE EER RE EEE EEE A eee 
create procedure %PROC% (IN jo_num char(5), cont_type char(1)) 
begin 
declare current_fy_end date; 
declare sum_actual numeric(12,2); 
declare sum_proj numeric(12,2); 
declare sum_cont numeric(12,2); 
declare begin date date; 


select CURRENT FY END DATE into current_fy_end from FMS _ CFG; 


select DATE RECEIVED into begin date from ACCOUNT 
where ACCOUNT JON=jo_num; 


select sum(ACTUAL_ COST) into sum_actual from CONTRACTS 
where CONTRACTS.JON = jo_num 
and CONTRACTS.CONTRACT_ TYPE = cont_type 
and CONTRACTS.FY_ENDING >= begin_date 
and CONTRACTS.FY_ ENDING <= current_fy_end; 


if (sum_actual is null) then 
set sum_actual = 0.00 
end if; 


select sum(PROJ_ COST) into sum_proj from CONTRACTS 
where CONTRACTS.JON = jo_num 
and CONTRACTS.CONTRACT_ TYPE = cont_type 
and CONTRACTS.ACTUAL COST is null 
and CONTRACTS.FY ENDING >= begin_date 
and CONTRACTS.FY_ ENDING <= current_fy_end; 


if (sum_proj is null) then 
set sum_ proj = 0.00 
end if; 


set sum_cont = sum_actual + sum_proj; 


Wy 


if (cont_type = 'M’) then 
update ACCOUNT 
set BAL_CONT_MIPR = INIT_CONT_MIPR - sum cont 
where ACCOUNT.JON = jo_num 


else 
if (cont_type = 'T') then 
update ACCOUNT 


set BAL_CONT_IPA = INIT_CONT_IPA - sum cont 
where ACCOUNT.JON =jo_num 


else 
if (cont_type = 'O') then 
update ACCOUNT 


set BAL CONT_OTH = INIT_CONT_OTH - sum _cont 
where ACCOUNT.JON = jo_num 
end if 
end if 
end if; 


end 
/ 


OAC CC ACI I IO A RE EKO, 


0/2 A A A ek oa a oR AK  KO/, 


% Procedure CALC BAL FAC LABOR 
Cat Ft TEETER EEE EER EERE EEE EEE EE ERE EEE Oo ee 
create procedure %PROC% (IN jo_num char(5)) 
begin 
declare current_fy_ end date; 
declare begin date date; 
declare sum_chg numeric(12,2); 


select CURRENT FY END DATE into current_fy_end from FMS CFG; 


select DATE RECEIVED into begin date from ACCOUNT 
where ACCOUNT JON=jo_num; 


select sum(TOTAL CHG) into sum_chg from LABOR_CHGS, FACULTY 
where FACULTY.EMP ID CODE =LABOR CHGS.EMP ID CODE 
and LABOR _CHGS.JON = jo_num 
and LABOR _CHGS.FY ENDING >= begin_date 


We 


and LABOR_CHGS.FY_ ENDING <= current_fy_end; 


if (sum_chg is null) then 
set sum_chg = 0.00 
end if: 


update ACCOUNT 
set BAL FAC LABOR = INIT_FAC LABOR $ - sum_chg 
where ACCOUNT. JON = jo_num; 
end 
/ 


Oo OS OS A EO OB GO He OE EO Oe OE Oe ee el ee ee tO 


LITERS ose SST Ne Ie aE ec I A Se Ot es Se Ma tee ie ee a ee a st a Sl) A 


% Procedure CALC BAL OPTAR 
Oy acct a Fr Are Fe eA eo aoe Oe ORE EOE A oe ee ee 
create procedure %PROC% (IN jo_num char(5)) 
begin 
declare current_fy_ end date; 
declare sum_actual numeric(12,2); 
declare sum_ proj numeric(12,2); 
declare sum_optar numeric(12,2); 
declare begin_date date; 


select CURRENT FY END DATE into current_fy_end from FMS_CFG; 


select DATE RECEIVED into begin_date from ACCOUNT 
where ACCOUNT JON=jo_num; 


select sum(ACTUAL_COST) into sum_actual from OPTAR_REQ 
where OPTAR REQ.JON =jo_num 
and OPTAR REQ.FY ENDING >= begin date 
and OPTAR REQ.FY ENDING <= current_fy_end; 


if (sum_actual is null) then 
set sum_actual = 0.00 
end if; 


select sum(PROJ_ COST) into sum_proj from OPTAR_REQ 
where OPTAR REQ JON = jo_num 


and OPTAR REQ.ACTUAL COST is null 
and OPTAR REQ.FY ENDING >= begin date 
and OPTAR REQ.FY_ ENDING <= current_fy_end; 


if (sum_proj is null) then 
set sum_ proj = 0.00 
end if: 


set sum_optar = sum_actual + sum_proj; 


update ACCOUNT 
set BAL_ OPTAR = INIT_OPTAR _$ - sum_optar 
where ACCOUNT.JON = jo_num; 
end 
/ 


ee EEE EEE ETE ERA ESE ee eee ee, 


OC ICICI ICICI ICICI I ACC IC I ACA I ACA a AC a A O/, 


Yo Procedure CALC_ BAL SPT LABOR 
Of, FREE EE AA EA EEE EE A A EERE REE EAE EEE EE ER EEE ER OG 
create procedure %PROC% (IN jo_num char(5)) 
begin 
declare current_fy_end date; 
declare begin date date; 
declare sum_chg numeric(12,2); 


select CURRENT FY END DATE into current_fy_end from FMS_CFG; 


select DATE RECEIVED into begin_date from ACCOUNT 
where ACCOUNT. JON=jo_num; 


select sum(TOTAL CHG) into sum_chg from LABOR_CHGS, STAFF 
where STAFF.EMP ID CODE = LABOR CHGS.EMP_ ID CODE 
and LABOR _CHGS.JON = jo_num 
and LABOR _CHGS.FY ENDING >= begin_date 
and LABOR _CHGS.FY ENDING <= current_fy_end; 


if (sum_chg is null) then 


set sum_chg = 0.00 
end if; 
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update ACCOUNT 
set BAL _SPT_ LABOR = INIT_SPT_LABOR $ - sum_chg 
where ACCOUNT.JON = jo_num; 
end 


Of EERE EREREKERR ERE REE KEK EREEEES EE ERE Do. 


Ct FEE EEE EERE RE ERA ERE ELEAE AEE EES EERE EL EES EEE Ee 0 


% Procedure CALC BAL TRAV 


CL RR TEESE RELEASE ERAT RE ee ee ee ee 
create procedure %PROC% (IN jo_num char(5)) 

begin 

declare current_fy_end date; 

declare sum_actual numeric(12,2); 

declare sum_proj numeric(12,2); 

declare sum_trav numeric(12,2); 

declare begin date date; 


select CURRENT FY END DATE into current_fy_end from FMS_CFG; 


select DATE RECEIVED into begin_date from ACCOUNT 
where ACCOUNT. JON=jo_num; 


select sum(ACTUAL COST) into sum_actual from TRAVEL 
where TRAVEL.JON =jo_num 
and TRAVEL.FY_ ENDING >= begin_date 
and TRAVEL.FY_ ENDING <= current_fy_end; 


if (sum_actual is null) then 
set sum_actual = 0.00 
end if: 


select sum(PROJ_ COST) into sum_proj from TRAVEL 
where TRAVEL.JON = jo_num 
and TRAVEL.ACTUAL COST is null 
and TRAVEL.FY ENDING >= begin_date 
and TRAVEL.FY_ENDING <= current_fy_end; 


if (sum_ proj is null) then 
set sum_proj = 0.00 


fs 


end if; 
set sum_trav = sum_actual + sum_proj; 


update ACCOUNT 
set BAL TRAVEL = INIT TRAVEL $ - sum_trav 
where ACCOUNT.JON = jo_ num; 
end 
/ 


Oe tectce oh ob A ae a Ae a a a oe oe 2 ae a A a ee 
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APPENDIX D. FMS POWERBUILDER LIBRARY OBJECT LISTING 


The FMS PowerBuilder library object listing 1s shown on the next page. 


Te) 





“=Jor_tms 


CPT fms_eecet pb 


! hae 
ay! 
ey 
a 
Fa] 
a! 
} 


(2D fms_ emp. pb! 







CER fms_mnt. pbi 


E 


a 


(fT fms_rpt pb 


ee ee fe} =) 
(LD tms_ mein. pbl 


fms_secc2.pbl 
= w_acct_detail 
= w_acct_Iist 


Ed w_scet_search 3/4/97 18:23:03 (198976) 


d_ scct_categones 
diacect_ contract. irt 
fas} d_scct_hesding 
d_scct_labor_lsst 
CE d_acct_ist 

(ras) d_ecct_opter_ist 
d_acct_trevel_list 

ore | d_sponsor_list 

Ed w_sponsor_lItst 


C=") d employec_detatt 
d_employee_Irst 

(ee } d_employes_list_prnt 
we s_emp_struc 

Et w_employee_detaill 
i=] w_employee_list 

EY w_employee_search 





= mocha 

ae or fms 

m_mecnu 

EZ w_fms_ about 

eS w_mamnlramewindow 
= W_password 

= | w_toolbars_contig 


d_ contracts_detai 
re} a@_labor_chargc_lrst 
d_iebor_les 
(at d_optar_ detail 

d_other_leave_lst 
[a} d_sponsor_detell 
[na} d_travel_detail 
EJ d_treveller_hst 


Fucully goocess madule lor FMS 
Main module tor ortms 
3/74/97 18°23:00 (2104) Financial Management System for the OR Dapartment 


3/4/97 18:22 57 [1282 


Account releted objects used solely by or_fms 
3/4/97 18:23 035 (438393) 
3/4/97 13.23.02 (13954) 


Account releted objects shared by both or_tms and faculty executables 


1) 


3/4/97 18:22:57 (5634) 
3/4/97 18:22:57 (16642) 
3/4/97 1822.56 (8596) 
3/74/97 16:22.56 (5334) 
3/4/97 18:22:56 (10264) 
3/4/97 18:22:57 {6895) 
3/74/97 16:2257 (7025) 
3/4/97 18:23:04 (14146) 


For employees releted abject= 
d_emp_acct_summary 3/4/97 18 22:57 


(S764) 


3/4/97 18.22:57 (1597) 
3/4/97 18:22:57 (4698) 
3/74/97 18:22:57 (6932) 
3/4/97 18 23:04 (355) 
3/4/97 18:23:04 (19147) 
3/4/97 18:23:05 (17168) 
3/4/97 18 23:05 (9586) 


374/97 18 23.33 (3055) 
374/97 18:23:01 (1969 
374/97 18.23:00 (3018 
374/97 16 23.01 (244) 
374/97 18.23.01 (1116 
3/4/97 18.23:02 (1536 


3/74/97 18 22 58 
3/78/97 18° 22:58 
3/4/97 18:22:58 
374/97 18 22 58 
374/97 13.22.58 
3/74/97 18:22:57 
3/74/97 18 2257 
3/4/97 18 2257 


Ex w_contracts_mamtcnance 3/74/97 13:22:05 


Ed w_lebor_maintenence 
=} w_opter mamtanance 
=" w_sponsor_marntensunce 
Ed w_travel_mamtenence 
(TD) fms_mnt2 pbi 


a Id_secct_detail 

cha d_cmployee 

[aa=} d_feculty 

fal d_tabor_acct_list 


3/4/97 16:23:06 
3/74/97 18 23 06 
3/4/97 18.23.07 
3/74/97 18: 23:07 


3/74/97 18 22 58 
3/4/97 18.22:58 
3/74/97 18:22:58 
3/74/97 18 2258 


ee | d_labor_done_employee_Irct 3/4/97 18.2258 


[aa*} d_labor_employee_ist 
[aa-} d_miltary 
3 d_pr_detall 


4_ start 


Ef w_scct_maintenance 


— w_amployee_maimtenance 


e w_labor 
ES w_ppedate 


oe) d_acct_contract_rpt 

FEld_acct_optar_rpt 

faa-} d_ecct_pi_list 

d_acct_travel_rpt 

co d_dsr_chgs 

(}q_dt_chgs 

[earl d_laculty_cert_rpt 

fae) d_lacullty_cert view 

bach d_other_leave 

d_proy_ status_rmpt 
dom echas 

=") d_st_Imt_chgs 

[aas} d_st_r_chg: 
d_st_omn_chgs 

eee | d_st_ot_echgs 

=) d_stin_chg: 

[aa-} d_stotf_cert_rpt 

a) d_ staff_cert_wew 

akc d_travellers_rpt 

Et w_acct_contract_rot 

N= w_eacct_optar_rpt 

= w_ecect_trovel_rpt 

ES w_faculty_cert_rpt 

=! W_ProLstatus_rpt 

Et w_erepornt selection 

eS w_stolt_cert_rpt 





3/4/97 18:22:58 
3/4/37 18-2258 
3/4/97 18 2258 
3/4/97 18:22:58 
3/4797 18:23:07 
3/4/97 18 23 08 
374/97 18.23.09 
3/4/97 18:23:09 


13 
) 
} 
5) 
0} 


Maintenance related objects sheared by both or_fms end laculty executables 


(11312) 
(5538) 
(7271) 
(1 2027) 
(4565) 
{7703} 
(7665) 
(4449} 
(14688) 
(25228) 
(13789) 
{18218) 
(181714) 


Meintanance relatad obrects used solely by or_fms 


(15286) 
(14496) 
(38368) 
(4554) 
(5184) It ol employees whose les are done: 
(5384] 
(3867) 
(2729) 
(3858] 
(18457} 
(1 7666) 
(48640) 
fS668e) 


Report related entnes for OR FM5 


3/74/97 18 23:00 (20697) 
3/4/97 18 23:00 (19297) 
3/4797 18:23:00 (3133) 


3/74/97 18 2300 (1921 
3/4/97 18.23.00 (2688 


1) 
} 


3/4/97 18.23:00 (2695) 
3/74/97 18 22:59 (18239) 
3/4/97 16 22:59 (13787} 
3/74/97 18:23:00 {3134} 
3/74/97 18:22:59 (206989) 
374/97 18 23:00 (3127) 
3/4/97 18 23.00 [2774) 
3/4/97 18:23:00 (3185) 
3/74/97 1823-00 (2715) 
3/74/97 18 2300 (3198) 
374/97 1823:00 (3147) 
3/4/97 18:22:59 (18474) 
374/97 18 22.59 (15199) 
3/4/97 18.22.59 [2581) 
3/4/97 1823:09 (10300) 
3/4/97 1823-10 (10257) 
3/4/97 16 23.10 {10372} 
3/4/97 18.23:10 (16681) 
3/74/97 18 23:10 (6350) 
3/4/97 182311 (6251) 
3/4/97 18.23.11 (16615) 
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APPENDIX E. FMS APPMODELER REPORT 


The partial AppModeler report produced from the FMS physical data model begins on the 
next page. 


12 


Physical Data Model fms 


-— ee SS SS SSS SS sss ssp > 


Full PDM report 
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Physical Data Model fms 


Model Information 


Project Name: fms 

Project Code: FMS 

Database: Watcom SQL 4.0 
Name: fms 

Code: FMS 


Label: Ops Research Dept Financial Management System 

Author: Alan E. Pires 

Version: 1.01 

Created On: 11/30/95 8:01 AM Modified On: 2/3/97 4:51 PM 





Model Description 


Financial Management System for the Operations Research Department 


Begin Script 


End Script 


Business Rules 
Domains 


Tables 


Table List 












account ACCOUNT 






adp_proj_info ADP_PROJ_INFO 

contracts CONTRACTS 

department DEPARTMENT 
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Physical Data Model 


a 


employee 
faculty 
fms_cfg 
labor_chgs 
labor_les 
military 
optar_req 
other_leave 
other_Iv_type 
pl 
salary_history 
sponsor 

Staff 

travel 
travel_requests 


Table account 


Name: 

Code: 

Label: 
Number: 

PK constraint: 


Options 


Column List 


EMPLOYEE 
FACULTY 
FMS_CFG 
LABOR_CHGS 
LABOR_LES 
MILITARY 
OPTAR_REQ 
OTHER_LEAVE 
OTHER_LV_TYPE 
P| 
SALARY_HISTORY 
SPONSOR 

STAFF 

TRAVEL 
TRAVEL_REQUESTS 


Account Information 


fms 


oF © OD 2 2 2 Oo Oo aro oO Go oO 





Pp Name | ote SY Ttype | POM 


bal_cont_ipa 
bal_cont_mipr 


bal_cont_oth 


S-Designor 


BAL_CONT_IPA 
BAL_CONT_MIPR 


BAL_CONT_OTH 


March 11, 1997 
§2 


decimal(12]No | No 
2) 
decimal(12]No {No 
2) 
decimal(12} No [No 
2) 
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Physical Data Model fms 

bal_fac_labor BAL_FAC_LABOR decimal(i2}No | No 
2) 

bal_optar BAL_OPTAR decimal(12]No j|No 
4), 

bal_spt_labor BAL_SPT_LABOR decimal(12]No {No 
2) 

bal_travel BAL_TRAVEL decimal(12}No j|No 
2) 

budget_page_date BUDGET_PAGE_DATE date No {No 

date_received DATE_RECEIVED date No [No 

expir_date EXPIR_DATE date No | No 

fund_type FUND_TYPE char(2) No {Yes 

indirect_cost INDIRECT_COST decimal(i2}No | Yes 
| »2) 

init_cont_ipa INIT_CONT_IPA decimal(i2]No | Yes 
2) 

init_cont_mipr INIT_CONT_MIPR decimal(i2}No {Yes 
2) 

init_cont_oth INIT_CONT_OTH decimal(i2]No | Yes 
2) 

init_fac_labor_$ INIT_FAC_LABOR_$ decimal(12]No | Yes 
2) 

init_optar_$ INIT_OPTAR_$ decimal(12]|No | Yes 
re) 

init_spt_labor_$ INIT_SPT_LABOR_$ decimal(12]No | Yes 
,2) 

init_travel_$ INIT_TRAVEL_$ decimal(12{No j Yes 
,2) 

jon JON char(5) Yes | Yes 

labor_jon LABOR_JON char(5) No {No 

remarks REMARKS char(100) {No {No 

segment_#s SEGMENT_#S char(9) No | No 

serial_#s SERIAL_#S char(11) No | No 

spon_id_code SPON_ID_CODE char(6) No | No 

title TITLE char(40 No |No 

BAL_CONT_IPA 

Check 
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Physical Data Model fms 


Domain: 
Low value: 
High value: 


Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





BAL_CONT_MIPR 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





BAL_CONT_OTH 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





S-Designor March 11, 1997 Page 84 
84 


Physical Data Model fms 





BAL_FAC_LABOR 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





BAL_OPTAR 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





BAL_SPT_LABOR 


Check 


Domain: 
Low value: 
High value: 


Default value: 
Unit: 
Format: 
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Physical Data Model fms 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





BAL_TRAVEL 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





BUDGET_PAGE_DATE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





DATE_RECEIVED 


Check 
Domain: 
Low value: 
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Physical Data Model fms 


High value: 
Default value: 


Unit: 

Format: 

Uppercase: lowercase: No Can't modify: No 
List of values: 





EXPIR_DATE 


Check 


Domain: 

low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





FUND_TYPE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





INDIRECT_COST 
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Physical Data Mode! fms 





Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





INIT_CONT_IPA 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





INIT_CONT_MIPR 


Check 


Domain: 

Low value: 
High value: 
Default value: 
Unit: 


Format: 
Uppercase: Lowercase: No Can't modify: No 
List of values: 
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Physical Data Model fms 





INIT_CONT_OTH 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 
Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





INIT_FAC_LABOR_$ 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





INIT_OPTAR_$ 


Check 


Domain: 
Low value: 


High value: 
Default value: 
Unit: 
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Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





INIT_SPT_LABOR_$ 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





INIT_TRAVEL_$ 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





JON 


Check 
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Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





LABOR_JON 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





REMARKS 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





SEGMENT_#S 
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Physical Data Model fms 





Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 
Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





SERIAL_#S 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





SPON_ID_CODE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 
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Physical Data Model fms 





TITLE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 
Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





Index List 






















Index Code P{rFiulc. Column Code esc! 
ACCOUNT _FK1 o [Yes |No ce SPON_ID_CODE 
ACCOUNT PK No |Yes JON ASC 





Reference to List 


Foreign Key 
SPONSOR SPON_ID_CODE SPON_ID_CODE 


Reference by List 


Referenced by Primary Key Foreign Key 


TRAVEL 
LABOR_CHGS 


CONTRACTS 
OPTAR_REQ 
P| 





Table adp_proj_info 
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Physical Data Model fms 


Name: adp_proj_info 
Code: ADP_PROJ_INFO 


Label: ADP Project Information 
Number: 
PK constraint: 





Options 


Column List 


adp_proj_# ADP_PROJ_# char(7) 
dept_code DEPT _CODE char(2) 
fy_ending FY_ENDING date 
poc_code POC_CODE char(4) 
proj_cost_auth PROJ _COST_AUTH decimal(12 


proj_mgr_code PROJ_MGR_CODE 
] PROJ NAME 





ADP_PROJ # 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





DEPT_CODE 
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ee 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: 
List of values: 





FY_ENDING 


Check 


Domain: 

Low value: 

High value: 

Default value: 09/30/97 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: 
List of values: 





POC_CODE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: 
List of values: 
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PROJ_COST_AUTH 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





PROJ_MGR_CODE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





PROJ_NAME 


Check 


Domain: 
Low value: 


High value: 
Default value: 
Unit: 
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Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





index List 


Index Code 


ADP_PROJ_INFO_FK1 
ADP_PROJ_INFO_FK2 
ADP_PROJ_INFO_FK3 
ADP_PROJ INFO PK 


Column Code | Sort 


DEPT_CODE 
PROJ_MGR_CODE 
POC_CODE 

ADP_PROJ # 



















Reference to List 


Primary Key Foreign Key 


DEPARTMENT DEPT_CODE DEPT_CODE 
EMPLOYEE EMP_ID_CODE PROJ_MGR_CODE 
EMPLOYEE EMP_ID CODE POC_CODE 

















Reference by List 


Referenced by Primary Key Foreign Key 
OPTAR_REQ ADP_PROJ_# ADP_PROJ # 


Table contracts 


Name: contracts 
Code: CONTRACTS 


Label: Departmental Contracts (charged to departmental accounts) 
Number: 
PK constraint: 





Options 
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Description 
Departmental Contracts (charged to departmental accounts) 


Column List 


actual_cost 


contract_type 
contractor 
delivery_date 
description 
doc _# 


fy_ending 
jon 
order_date 


ACTUAL_COST 


Check 


Domain: 


Low value: 
High value: 
Default value: 


Unit: 
Format: 


Uppercase: 
List of values: 


CONTRACT TYPE 


S-Designor 


ACTUAL_COST 


CONTRACT_TYPE 
CONTRACTOR 
DELIVERY_DATE 
DESCRIPTION 
DOC_# 
FY_ENDING 

JON 
ORDER_DATE 
PO # 

PO DATE 

PROJ COST 


REQUESTER 


Lowercase: No 


March 11, 1997 


98 


decimal(12 | No 
2) 
char(1) 
char(20) 
date 
char(50) 
char(9) 
date 
char(5) 
date 
char(12) 
date 


decimal(12 
2) 





Can't modify: No 
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Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: 
List of values: 





CONTRACTOR 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: 
List of values: 





DELIVERY_DATE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: 
List of values: 





S-Designor March 11, 1997 Page 99 
99 


Physical Data Model fms 





DESCRIPTION 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





DOC # 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





FY_ENDING 


Check 


Domain: 
Low value: 


High value: 
Default value: 9/30/97 
Unit: 
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Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





JON 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





ORDER_DATE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





PO # 


Check 
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Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





PO_DATE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





PROJ_COST 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





REQUESTER 


S-Designor March 11, 1997 Page 102 
102 


Physical Data Model fms 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 
Format: 





Index List 





Uppercase: Lowercase: No Can't modify: No 

List of values: 

Index Code pieiulc Column Code |__Sort__ 

CONTRACTS_PK Yes Yes JON ASC 
CONTRACT_TYPE ASC 

Reference to List 

Primary Key Foreign Key 


REQUESTER ASC 
EMPLOYEE EMP_ID_CODE REQUESTER 


DOC # ASC 
Table department 


























Name: department 
Code: DEPARTMENT 


Label: Department Info 
Number: 
PK constraint: 





Options 
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Column List 


J Name ode type | 





chair_code CHAIR_CODE No | No 
dept_code DEPTZCODE Yes | Yes 
DEPT NAME No | No 


CHAIR_CODE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





DEPT_CODE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





DEPT NAME 
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Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





Index List 


| indexcode | P| F | UL GC {| Columncode | Sort 
[DEPARTMENT.PK ses No _JYes JNo [DEPT.CODE CAS 


Reference by List 


Referenced by Primary Key Foreign Key 


EMPLOYEE DEPIZCOBE DEPT_CODE 
ADP_PROJ_INFO DEPTSZCODE DEPT CODE 


Table employee 






Name: employee 
Code: EMPLOYEE 


Label: Employee Information 
Number: 
PK constraint: 





Options 


Column List 
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accel_rate 


base_salary 


bidg_# 
category 

city 
dept_code 
eff_sal_date 
emp_code 
emp_id_code 
first name 
home_phone 
last_name 

mi 

room_# 
spouse_fname 
ssn 

state 

street address 
term_date 
work_phone 
zipcode 


ACCEL_RATE 


Check 


Domain: 

Low value: 
High value: 
Default value: 
Unit: 

Format: 
Uppercase: 
List of values: 


S-Designor 


ACCEL_RATE 
BASE_SALARY 


BLDG # 
CATEGORY 

CITY 

DEPT_CODE 
EFF_SAL_DATE 
EMP_CODE 
EMP_ID_ CODE 
FIRST_NAME 
HOME_PHONE 
LAST_NAME 

MI 

ROOM_# 
SPOUSE_FNAME 
SSN 

STATE 
STREET_ADDRESS 
TERM_DATE 
WORK_PHONE 
ZIPCODE 


Lowercase: No 
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char(4) 
char(15) 
char(13) 
char(15) 
char(1) 
char(5) 
char(15) 
char(11) 
char(2) 
char(20) 


Can't modify: No 
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BASE_SALARY 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





BLDG # 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





CATEGORY 


Check 


Domain: 
Low value: 
High value: 


Default value: 
Unit: 
Format: 
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Uppercase: No Lowercase: No Can't modify: No 
List of values: 


CITY 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





DEPT _CODE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





EFF_SAL_DATE 


Check 
Domain: 
Low value: 
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High value: 
Default value: 10/01/95 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: 
List of values: 





EMP_CODE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: 
List of values: 





EMP_ID_CODE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: 
List of values: 





FIRST_NAME 
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Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





HOME_PHONE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





LAST_NAME 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 
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Mil 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





ROOM_# 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





SPOUSE FNAME 


Check 


Domain: 
Low value: 


High value: 
Default value: 
Unit: 





S-Designor March 11, 1997 Page 111 
11] 


Physical Data Mode! fms 


Format: 


Uppercase: lowercase: No Can't modify: No 
List of values: 





SSN 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





STATE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





STREET ADDRESS 


Check 
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Low value: 
High value: 
Default value: 
Unit: 


Format: 
Uppercase: Lowercase: No Can't modify: No 
List of values: 





TERM_DATE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





WORK_PHONE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





ZIPCODE 
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Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 
Uppercase: 
List of values: 


index List 






EMPLOYEE FK1 O 
EMPLOYEE PK Yes 


Lowercase: 





-F}ufect{ cColumncode _—|_—Sont_ 
EPT_CODE 
MP_ID CODE ASC 


es 


Y 
Yes 





No No {TD 
Yes INo [TE 


Can't modify: No 









Reference to List 


Primary Key Foreign Key 
DEPARTMENT DEPT CODE DEPT CODE 


Reference by List 


Referenced by Primary Key Foreign Key 


LABOR_CHGS 
OPTAR_REQ 
SALARY_HISTORY 
PI 

CONTRACTS 


LABOR_LES 
FACULTY 

STAFF 
MILITARY 
ADP_PROJ_INFO 
ADP_PROJ_ INFO 
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EMP_ID_CODE 
EMP_ID_CODE 
EMP_ID_CODE 
EMP_ID_CODE 
EMP_ID_CODE 
EMP_ID_CODE 
EMP_ID_CODE 
EMP_ID_CODE 
EMP_ID_CODE 
EMP_ID_CODE 
EMP_ID CODE 
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EMP_ID_CODE 
EMP_ID_CODE 
EMP_ID_CODE 
EMP_ID_CODE 
REQUESTER 
EMP_ID_CODE 
EMP_ID_ CODE 
EMP_ID_CODE 
EMP_ID_CODE 
PROJ_MGR_CODE 
POC_CODE 
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Table faculty 


Name: faculty 
Code: FACULTY 


Label: Faculty Specialization of Employee Table 
Number: 
PK constraint: 





Options 


Column List 


Name —“(tié‘iLC( C“‘CCOde:~ —C—‘iSCType «S| PM 
civ_grade CIV_GRADE No |No 
emp_id_code EMP_ID_CODE Yes | Yes 
step STEP No |No 


CIV_GRADE 





Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: Can't modify: No 
List of values: 





EMP_ID_CODE 


Check 
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a 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





STEP 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





Index List 


| indexcode | P| Fh | UU | cc | Columncode 


Th 
> 
QO 
G 
2 
U 
| 
| 
© 
n 
a 
© 
7) 
ie 
© 
7) 
5 
Oo 
Mm 
< 
U 
s) 
2) 
O 
O 
mM 
ia 
” 
‘@) 


Reference to List 


Primary Key Foreign Key 
EMPLOYEE EMP_iD_CODE EMP_ID_CODE 


Table fms_cfg 





Name: fms_cfg 
Code: FMS_CFG 
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Label: 
Number: 
PK constraint: 


FMS Configuration Info 


fms 





Options 


Column List 


current_fy_end_date 
ot_cap 


rr_ot_rate_fact 


r labor hrs 


CURRENT_FY_END_ DATE 


Check 


Domain: 

Low value: 
High value: 
Default value: 
Unit: 

Format: 
Uppercase: 
List of values: 


OT_CAP 


Check 


Lowercase: No 


CURRENT _FY_END_ DATE 
OT_CAP 


RR_OT_RATE_FACT 


YR_LABOR_HRS 





Can't modify: No 





Domain: 
Low value: 
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High value: 
Default value: 


Unit: 
Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





RR_OT_RATE_FACT 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





YR_LABOR_HRS 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





index List 
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| indexcode | P| Fh] UU cc | Columncode | Sort _ 
INo_ [Yes [No [CURRENT.FY_END_ DATE |ASC 


Table labor_chgs 


Name: labor_chgs 
Code: LABOR_CHGS 


Labe!: Labor charges made against accounts 
Number: 
PK constraint: 





Options 


Description 


This table contains the labor charges made against accounts by pay period ending date and employee. 


Column List 


emp_id_code EMP_ID_CODE char(4) 
fy_ending FY_ENDING date 
hours HOURS integer 
jon JON char(5) 
ot_hours OT_HOURS integer 
ppe_date PPE DATE date 


total_chg TOTAL_CHG decimal(12 
2D 





EMP_ID CODE 


Check 


Domain: 


Low value: 
High value: 
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Default value: 
Unit: 


Format: 


Uppercase: lowercase: No Can't modify: No 
List of values: 





FY_ENDING 


Check 


Domain: 

Low value: 

High value: 

Default value: 9/30/97 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





HOURS 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





JON 


Check 
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Domain: 
Low value: 
High value: 


Defauit value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





OT_HOURS 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





PPE_DATE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 
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TOTAL_CHG 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 
Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





index List 


Index Code /F [utc t|  cCoumncode | Sort _ 


LABOR_CHGS_PK Yes -Yes |Yes [No J|EMP_ID_CODE ASC 
PPE_DATE 
JON 


Reference to List 


Primary Key Foreign Key 


LABOR_LES EMP_ID_CODE EMP_ID_ CODE 
PPE DATE PPE DATE 
ACCOUNT JON JON 


EMPLOYEE EMP_ID CODE EMP_ID_ CODE 









Table labor_les 


Name: labor_les 
Code: LABOR_LES 


Label: Labor -- Leave and Holiday Charges 
Number: 
PK constraint: 
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Options 


Column List 


al_hours AL_HOURS integer 
emp_id_code EMP_ID_CODE char(4) 


hol_hours HOL_HOURS integer 
lwop_hours LVWOP_HOURS integer 
ppe_date PPE_DATE date 
s|_hours SL_HOURS 





AL_HOURS 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





EMP_ID_CODE 


Check 


Domain: 
Low value: 
High value: 


Default value: 
Unit: 
Format: 
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Uppercase: No Lowercase: No Can't modify: No 
List of values: 


HOL_HOURS 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





LWOP_HOURS 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: NO Can't modify: No 
List of values: 





PPE_DATE 
Check 

Domain: 

Low value: 
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High value: 
Default value: 


Unit: 
Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





SL_HOURS 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





Index List 


Index Code Pietutct|{  coumncode 





LABOR_LES PK Yes |No | Yes EMP_ID CODE 
PPE DATE ASC 


Reference to List 


Primary Key Foreign Key 
EMPLOYEE EMP_ID_CODE EMP_ID CODE 


Reference by List 


Referenced by Primary Key Foreign Key 


LABOR_CHGS EMP_ID_CODE | EMP_ID_CODE 
PPE DATE PPE_DATE 
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OTHER_LEAVE EMP_ID_CODE EMP_ID_CODE 
PPE DATE FRE DATE 


Table military 


Name: 
Code: 


Label: 
Number: 
PK constraint: 


Options 


Column List 


emp_id_code 
mil_grade 
service 


EMP_ID_CODE 


Check 


Domain: 

Low value: 
High value: 
Default value: 
Unit: 

Format: 
Uppercase: 
List of values: 


MIL_GRADE 


S-Designor 


military 
MILITARY 
Military Specialization of Employee Table 


EMP_ID_CODE 
MIL_GRADE 
SERVICE 


Lowercase: No 


March 11, 1997 


126 


Can't modify: 


No 
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Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 
Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





SERVICE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 


Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





index List 
| iindexcode =| P| F | u | c { ColumnCode | Sort__ 
MILITARY. PK ——sSédL Yes Yes [Yes [No [EMP_ID CODE —————sFASC 


Reference to List 


Primary Key Foreign Key 
EMPLOYEE EMP_ID_CODE EMP_ID_CODE 


Table optar_req 
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Name: optar_req 
Code: OPTAR_REQ 


fms 


Label: OPTAR Request Information 


Number: 
PK constraint: 


Options 


Description 
OPTAR Request Information 


Column List 


actual_cost 


adp_proj_# 
category 
description 
doc_# 
emp_id_code 


fy_ending 
issued_by 
jon 
order_date 
po_# 
po_date 
proj_cost 





recvd date 


ACTUAL_COST 


Check 


S-Designor 





ACTUAL_COST 


ADP_PROJ_# 

CATEGORY 

DESCRIPTION 

Doc # 

EMP_ID_ CODE 

FY_ENDING 

ISSUED_BY 

JON 

ORDER_DATE 

PO # 

PO_DATE 

PROJ COST decimal(11 
2) 

RECVD DATE date 


March 11, 1997 Page 128 
128 


Physical Data Model fms 


Domain: 
Low value: 
High value: 


Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





ADP_PROJ_# 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





CATEGORY 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 
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DESCRIPTION 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





DOC # 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





EMP_ID CODE 


Check 


Domain: 
Low value: 
High value: 


Default value: 
Unit: 
Format: 
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Uppercase: Lowercase: No Can't modify: No 
List of values: 





FY_ENDING 


Check 


Domain: 

Low value: 

High value: 

Default value: 9/30/97 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





ISSUED _BY 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





JON 


Check 
Domain: 
Low value: 
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High value: 
Default value: 
Unit: 


Format: 
Uppercase: Lowercase: No Can't modify: No 
List of values: 





ORDER_DATE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





PO_# 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





PO DATE 
Oe 
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Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





PROJ_COST 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





RECVD_DATE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 
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index List 


| indexCode | PT FE | UC | ColumnCode | Sort_| 


OPTAR_REQ_FK1 No {Yes |No |No [ADP_PROJ_# 
OPTAR_REQ_PK Yes [No |Yes |No |JON 

EMP_ID_CODE 
DOC # 

















Reference to List 


Primary Key Foreign Key 


EMPLOYEE EMP_ID_ CODE EMP_ID_CODE 
ACCOUNT JON JON 
ADP. PROJ_INFO ADP_PROJ # ADP_PROJ # 





Table other_leave 


Name: other_leave 

Code: Olek EEAVE 

Label: "Other" leave info per employee per pay period 
Number: 

PK constraint: 





Options 


Description 


"Other" leave info per employee per pay period 


Column List 


emp_id_code EMP_ID_CODE 
hours HOURS 





EE 
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ppe_date PPE_DATE date Yes | Yes 
type aie char(2 Yes [| Yes 
EMP_ID_CODE 

Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





HOURS 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





PPE_DATE 


Check 


Domain: 


Low value: 
High value: 





S-Designor March 11, 1997 Page 135 


Physical Data Model fms 


Default value: 
Unit: 


Format: 
Uppercase: Lowercase: No Can't modify: No 
List of values: 





TYPE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





Index List 


| indexcode | P| Fh |u| Cc | Coumncode | Somt__ 


OTHER_LEAVE_PK Yes | Yes a EMP_ID_CODE ASC 
PPE_DATE 
TYPE 


Reference to List 


Primary Key Foreign Key 


LABOR_LES EMP_ID CODE EMP_ID_ CODE 






PPE DATE PPE_DATE 
OTHER _LV_TYPE OTHER LV_TYPE_CODE TYPE 





Table other_lIv_type 


Name: other_Iv_type 
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eer nn nn ree SS Sree i hp lessee SSS 


Code: OlmeRaly TYPE 
Label: Other Leave Type Lookup Table 


Number: 
PK constraint: 





Options 


Column List 


[Name Code pM 


description DESCRIPTION char(25) No | No 
other _lv_type code OURERTCY iy Peaecobe char(2 Yes | Yes 


DESCRIPTION 













Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





OTHER_LV_TYPE_CODE 


Check 


Domain: 
Low value: 


High value: 
Default value: 
Unit: 
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Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





Index List 


Index Code Ea es Column Code 
OTHER LV TYPE PK Yes Yes OTHER LV_TYPE_CODE ASC 


Reference by List 


Referenced by Primary Key Foreign Key 


OTHER_LEAVE OTHER_LV_TYPE_CODE TYPE 
Table pi 


Name: pi 
Code: P| 


Label: Principal Investigator 
Number: 
PK constraint: 





Options 


Column List 


[Name ——S*dtCsSCti oe 


emp_id_code EMP_!D_CODE char(4) Yes | Yes 
ion JON char(5 Yes | Yes 


EMP_ID_CODE 












Check 
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Domain: 
Low value: 
High value: 


Default value: 
Unit: 
Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





JON 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





Index List 


Index Code en 
Ye 


PI_PK S 


Reference to List 


Primary Key Foreign Key 


EMPLOYEE EMP_ID_CODE EMP_ID_CODE 
ACCOUNT JON JON 


Table salary_history 












-Fjulct|  columncode  _—'|_ Sort __ 
Yes | Yes 


EMP_ID_CODE ASC 
JON ASC 
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Name: salary_history 
Code: SALARY_HISTORY 


Label: Employee salary history (including acceleration rate) 
Number: 
PK constraint: 





Options 


Description 


Employee salary history (including acceleration rate) 


Column List 


accel_rate ACCEL_RATE 


base_salary BASE_SALARY decimal(10 
,2) 
begin_date BEGIN_DATE date 
emp_id_code EMP_ID_CODE char(4) 
end_date END DATE date 





ACCEL_RATE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 
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BASE SALARY 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





BEGIN_DATE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





EMP_ID_ CODE 


Check 


Domain: 
Low value: 
High value: 


Default value: 
Unit: 
Format: 
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Uppercase: Lowercase: No Can't modify: No 
List of values: 





END_DATE 


Check 


Domain: 

Low value: 
High value: 
Default value: 
Unit: 

Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





Index List 


| indexcode | P| EF | UU} GC | Columncode | Sort__ 


SALARY_HISTORY_PK Yes }INo [Yes [No |EMP_ID_CODE ASC 
BEGIN DATE ASC 


Reference to List 


Primary Key Foreign Key 
EMPLOYEE EMP_ID_CODE EMP_ID_CODE 









Table sponsor 


Name: sponsor 
Code: SPONSOR 


Label: Research Sponsor Info 
Number: 
PK constraint: 
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Options 


Column List 


address char(40) 
city CITY char(15) 
fax char(13) 


name NAME char(30) 
phone PHONE char(13) 
spon_id_code SPON_ID_CODE char(6) 
state STATE char(2) 
ZIPCODE char(10 





ADDRESS 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





CITY 


Check 


Domain: 
Low value: 


High value: 
Default value: 
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Unit: 


Format: 
Uppercase: Lowercase: No Can't modify: No 
List of values: 





FAX 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





NAME 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: NO Can't modify: No 
List of values: 





PHONE 
Check 
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Domain: 
Low value: 
High value: 


Default value: 
Unit: 
Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





SPON_ID_CODE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





STATE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 


Format: 
Uppercase: Lowercase: No Can't modify: No 
List of values: 
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ZIPCODE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





index List 
| indexcode = =—S—s | P| FL | UC] Columncode | Sort __ 
[SPONSOR PK__———sédt Yes: [No_|Yes [No [SPON_ID CODE —s———SC*dASC Cs 


Reference by List 


Referenced by Primary Key Foreign Key 


ACCOUNT SPON ID CODE SPON ID CODE 
Table staff 


Name: Staff 
Code: STAFF 


Label: Staff Specialization of Employee Table 
Number: 
PK constraint: 





Options 


Column List 
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Cciv_grade CIV_GRADE 
emp_id_code EMP_ID_CODE 
step Sher 





CIV_GRADE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





EMP_ID_ CODE 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





STEP 
Check 
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Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





Index List 


| indexcode | P| FE | uU{| cc | Columncode _—|_Soort 
STAFFPK es Jes [Yes [No [EMPID cope fASC 


Reference to List 


Primary Key Foreign Key 
EMPLOYEE EMP_ID_CODE EMP_ID_ CODE 


Table travel 


Name: travel 

Code: TRAVEL 

Label: Travel Order Info 
Number: 

PK constraint: 





Options 


Column List 


actual_cost ACTUAL_COST 





destination DESTINATION 
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a RE eee 


fy_ending 

jon 
num_trav_days 
proj_cost 


to# 


to_date 
trav_start_ date 


ACTUAL_COST 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 
Uppercase: 
List of values: 


DESTINATION 


Check 


Domain: 

Low value: 
High value: 
Default value: 
Unit: 

Format: 
Uppercase: 
List of values: 


FY_ENDING 


S-Designor 


FY_ENDING 

JON 
NUM_TRAV_DAYS 
PROJ_COST 


TO# 
TO_DATE 
TRAV_START DATE 


Lowercase: 


Lowercase: No 


March 11, 1997 
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date No | Yes 
char(5) No [Yes 
integer No [No 
decimal(10 | No {No 
2) 

char(15) Yes | Yes 
date No |No 
date No |No 


Can't modify: No 





Can't modify: No 
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Check 


Domain: 

Low value: 

High value: 

Default value: 09/30/1997 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





JON 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





NUM_TRAV_DAYS 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 
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PROJ_COST 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 
Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





TO# 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: Can't modify: No 
List of values: 





TO_DATE 


Check 


Domain: 
Low value: 


High value: 
Default value: 
Unit: 
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Format: 


Uppercase: Lowercase: No Can't modify: No 
List of values: 





TRAV_START_DATE 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





Index List 





Reference to List 


Primary Key Foreign Key 
ACCOUNT JON JON 


Reference by List 


Referenced by Primary Key Foreign Key 
TRAVEL REQUESTS TO# TO# 


Table travel_ requests 


Name: travel_requests 
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Code: 

Label: 
Number: 

PK constraint: 


Options 


Column List 


trav_fname 
trav_Iname 
trav_mi 


TO# 


Check 


Domain: 

Low value: 
High value: 
Default value: 
Unit: 

Format: 
Uppercase: 
List of values: 


TRAV_FNAME 


Check 


Domain: 


Low value: 


TRAVEL_REQUESTS 
Information on travelers for a specific Travel Order 


TRAV_FNAME 
TRAV_LNAME 
TRAV_MI 


Lowercase: 


fms 


Can't modify: 


No 














High value: 


S-Designor 
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Default value: 
Unit: 


Format: 
Uppercase: Lowercase: No Can't modify: No 
List of values: 





TRAV_LNAME 


Check 


Domain: 

Low value: 

High value: 

Default value: 

Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





TRAV_MI 


Check 


Domain: 

Low value: 
High value: 
Default value: 


Unit: 

Format: 

Uppercase: Lowercase: No Can't modify: No 
List of values: 





index List 
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SSL 
—- 











index Code 


TRAVEL_REQUESTS_PK 


Reference to List 


Cc Column Code 


TO# ASC 
TRAV_LNAME ASC 
TRAV_FNAME ASC 






Primary Key 
TRAVEL 
Views 

View List 


dr_chgs DR_CHGS 
dt_chgs DT_CHGS 
rr_chgs RR_CHGS 
st_fmt_chgs ST_FMT_CHGS 


st_ind_chgs ST_IND_CHGS 
st_ir_chgs ST_IR_CHGS 
st_omn_chgs ST_OMN_CHGS 
st_ot_chgs ST_OT_CHGS 
st_rr_chgs ST_RR_CHGS 
st_tuit_chgs ST_TUIT CHGS 





View dr_chgs 


dr_chgs 
DR_CHGS 
DR Charges View 


Query Only 
Generate View 





Code 
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select FACULTY.EMP_ID_CODE, LABOR_CHGS.PPE_DATE, LABOR_CHGS.HOURS 
from ACCOUNT, FACULTY, LABOR_CHGS 

where FACULTY.EMP_ID_CODE = LABOR_CHGS.EMP ID CODE 

and ACCOUNT.JON = LABOR_CHGS.JON 

and ACCOUNT.FUND_TYPE = 'DR' 


View dt_chgs 


dt_chgs 
DT_CHGS 
DT Charges View 


Query Only 
Generate View 





Code 


select FACULTY.EMP_ID CODE, LABOR_CHGS.PPE_DATE, LABOR_CHGS.HOURS 
from ACCOUNT, FACULTY, LABOR_CHGS 

where FACULTY.EMP ID CODE =LABOR_CHGS.EMP ID CODE 

and ACCOUNT.JON = LABOR_CHGS.JON 

and ACCOUNT.FUND_ TYPE = 'DT’ 


View rr_chgs 


rr_chgs 
RR_CHGS 
RR Charges View 


Query Only 
Generate View 





Code 


select FACULTY.EMP ID CODE, ACCOUNT.LABOR_JON, LABOR _CHGS.PPE_DATE, LABOR_CHGS.HOURS 
from ACCOUNT, FACULTY, LABOR_CHGS 

where FACULTY.EMP_ID CODE = LABOR_CHGS.EMP_ ID CODE 

and ACCOUNT.JON = LABOR_CHGS.JON 

and ACCOUNT.FUND_ TYPE = 'RR' 
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View st_fmt_chgs 


st_fmt_chgs 
ST_FMT_CHGS 
st_fmt_chgs 


Updatable 
Generate View 
With check option 





Code 


select STAFF.EMP_ID_ CODE, LABOR_CHGS.HOURS, LABOR_CHGS.PPE_DATE 
from STAFF, LABOR. CHGS 

where STAFF.EMP_ID_CODE = LABOR _CHGS.EMP_ID CODE 

and LABOR_CHGS.JON = 'FMT" 


View st_ind_chgs 


st_ind_chgs 
ST_IND_CHGS 
st_ind_chgs 
Updatable 
Generate View 
With check option 





Code 


select STAFF.EMP_ ID CODE, LABOR_CHGS.HOURS, LABOR_CHGS.PPE_DATE 
from STAFF, LABOR_CHGS 

where STAFF.EMP ID CODE = LABOR_CHGS.EMP_ID CODE 

and LABOR_CHGS.JON = 'IND' 


View st_ir_chgs 


St_ir_chgs 
ST_IR_CHGS 


st_ir_chgs 
Updatable 
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Generate View 
With check option 


Code 


select ACCOUNT.LABOR_JON, STAFF.EMP_ID_CODE, LABOR_CHGS.HOURS, LABOR_CHGS.PPE_ DATE 
from ACCOUNT, STAFF, LABOR_CHGS 

where STAFF.EMP_ID_CODE = LABOR _CHGS.EMP ID CODE 

and ACCOUNT.JON = LABOR_CHGS.JON 

and ACCOUNT.FUND_TYPE = 'IR' 





View st_omn_chgs 


st_omn_chgs 
ST_OMN_CHGS 
st_omn_chgs 


Updatable 
Generate View 
With check option 





Code 


select STAFF.EMP_ ID CODE, LABOR CHGS.HOURS, LABOR_CHGS.PPE DATE 
from STAFF, LABOR CHGS 

where STAFF.EMP_ ID CODE = LABOR CHGS.EMP_ID_ CODE 

and LABOR_CHGS.JON = 'O&MN' 


View st_ot_chgs 


st_ot_chgs 
ST_OT_CHGS 
st_ot_chgs 


Updatable 
Generate View 
With check option 





Code 
select ACCOUNT.LABOR_JON, STAFF.EMP_ID CODE, LABOR_CHGS.OT_HOURS, LABOR_CHGS.PPE_DATE 
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from ACCOUNT, STAFF, LABOR_CHGS 

where STAFF.EMP_ID CODE = LABOR _CHGS.EMP ID CODE 
and ACCOUNT.JON = LABOR_CHGS.JON 

and LABOR_CHGS.OT_HOURS > 0 


View st_rr_chgs 


Name: st_rr_chgs 
Code: ST_RR_CHGS 
Label: st_rr_chgs 


Usage: Updatable 
Generate View 
With check option 





Code 


select ACCOUNT.LABOR_JON, STAFF.EMP ID CODE, LABOR_CHGS.HOURS, LABOR_CHGS.PPE_DATE 
from ACCOUNT, STAFF, LABOR_CHGS 

where STAFF.EMP_ID CODE =LABOR_CHGS.EMP_ID_CODE 

and ACCOUNT.JON = LABOR_CHGS.JON 

and ACCOUNT.FUND_ TYPE = 'RR' 


View st_tuit_chgs 


St_tult_chgs 
ST_TUIT_CHGS 
st_tuit_chgs 


Updatable 
Generate View 
With check option 





Code 


select STAFF.EMP ID CODE, LABOR_CHGS.HOURS, LABOR_CHGS.PPE_DATE 
from STAFF, LABOR_CHGS 

where STAFF.EMP ID CODE = LABOR_CHGS.EMP_ID_ CODE 

and LABOR_CHGS.JON = 'TUIT' 


Triggers 
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fms 


Table Trigger User- 
Defined 


ACCOUNT 
ACCOUNT 
ACCOUNT 
ADP_PROJ_INFO 
CONTRACTS 
CONTRACTS 
CONTRACTS 
CONTRACTS 
CONTRACTS 
EMPLOYEE 
FACULTY 
LABOR_CHGS 
LABOR_CHGS 
LABOR_CHGS 
LABOR_CHGS 
LABOR_LES 
MILITARY 
OPTAR_REQ 
OPTAR_REQ 
OPTAR_REQ 
OPTAR_REQ 
OTHER_LEAVE 
OTHER_LEAVE 
P| 
SALARY_HISTORY 
STAFF 
TRAVEL 
TRAVEL 
TRAVEL 
TRAVEL 
TRAVEL_ REQUESTS 





Procedures 


S-Designor 


tib_ account 
tia_account 
fua_account 
tib_adp_proj_info 
tib_contracts 
tia_contracts 
tub_contracts 
tua_contracts 
tda_contracts 
tib_employee 
tib_ faculty 
tib_labor_chgs 
tia_labor_chgs 
tua_labor_chgs 
tda_labor_chgs 
tib_labor_les 

tib_ military 
tib_optar_req 
tia_optar_req 
tua_optar_req 
tda_optar_req 
tib_other_leave 
tub_other_leave 
tib_pi 
tib_salary_history 
tib_ staff 
tib_travel 
tia_travel 
tua_travel 
tda_travel 

tib travel_ requests 
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Procedure List 


calc_bal_contract CALC_BAL_CONTRACT 
calc_bal_fac_labor CALC_BAL_FAC_LABOR 


calc_bal_optar CALC_BAL_OPTAR 
calc_bal_spt_labor CALC_BAL_SPT_LABOR 
calc_bal_trav CALC_BAL_TRAV 





re 
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